APPENDIX A 



PROVISIONAL PATENT APPLICATION 
for 

INTEGRATED ACCESS DEVICE FOR 
ASYNCHRONOUS TRANSFER MODE (ATM) COMMUNICATIONS 



Inventors: Kenneth Wayne Brinkerhoff 
27825 Terales 

Mission Viejo, California 92692 

Wayne Paul Boese 
2053-A Tustin Avenue 
Costa Mesa, California 92627 

Robert C. Hutchlns 
24272 Solonica Street 
Mission Viejo, California 92692 

Stanley (NMI) Wong 
2509 West Hall Avenue 
Santa Ana, California 92704 



Attorney for Applicant: 

William G. Lane, Inc., P.C. 
18400 Von Karman Avenue, Suite 500 
Irvine, California 92612 
Telephone: 949 474-9961 
Telefax: 949 474-9973 

Attorney Docket No. M015-1001 Prov 



Express Mail No. EJ130608565US 
Date Mailed: June 30. 2000 



1 

2 

3 

4 

5 

6 

7 



INTEGRATED ACCESS DEVICE FOR ASYNCHRONOUS TRANSFER g 



r)~- — 

U 



MODE (ATM) COMMUNICATIONS 
BACKGROUND OF THE INVENTION 
A. Field of the Invention 

The present invention relates to the communication of information by electrical or optical 
signals. More particularly, the invention relates to an integrated access device apparatus and method 
for accessing digital information signals transmitted in an Asynchronous Transfer Mode (ATM), and 



8 I for converting voice, video and data information to ATM signals for transmission. 
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Description of Background Art 

Enterprises such as private companies, learning institutions, health care organizations and 
governmental agencies routinely must transfer information in a substantially instantaneous or "real time' 
fashion between locations which are too far apart to permit face-to-face contact. Such information 
transfers include voice and telefacsimile transmissions over existing telephone communication channels, 
digital data interchange between computers, including Internet communications, and video 
conferencing. 

Many enterprises also utilize a network of computer work stations located in individual 
offices or cubicles, which are interconnected with each other and sometimes with a larger computer 
which functions as a Server for the network. A Server typically has substantially greater memory storage 
and/or computational power than individual PCs (Personal Computers) located at employee work 
stations, and thus is often an expedient economic choice because the greater processing and memory 
capabilities of the Server, with the concomitant increases in size, power consumption and cost that these 
increased capabilities entail, need not be replicated in each work station PC. 

A variety of network interconnection configurations, or topologies are employed in the 
interconnection of computers at a given enterprise site. Such networks are frequently referred to as 
Local Area Networks or LANs because of the relatively close geographic proximity of the 
interconnected computers. A popular interconnection standard and data exchange protocol for LANs 
is refened to as the Ethernet. 

LANs as described above may be linked together to form a hi^er level, i.e., more 
broadly inclusive, network connecting geographically separated offices in a city, in a Metropolitan Area 



1 [ Network (MAN). MANs can be linked together to form a Wide Area Network (WAN), which might 

2 stretch nationwide, or to a worldwide network or Global Area Network (GAN), such as the Internet. 

3 Existing telephone communication lines which link telephones world-wide employ a 

4 I hierarchical interconnection scheme similar to that used between LANs at the user-end, node or "Edge" 

5 I at one end of a network, and the GAN spanning the globe at the other end Thus, enterprise sites are 

6 I frequently equipped with Private Branch Exchanges (PBXs) that interconnect telephones and enable 

7 telephone communications between employees at a particular site. Telephones within the PBX may be 

8 I connected to other sites in the same metropolitan area by a local PubUc Service Telephone Network 

9 I (PSTN) carrier. The latter in tum may be interconnected to other metropolitan areas within a country 
10 H by long distance or Wide Area teleconunxmications networks, which are in tum connected by 
111 conmiunication chaimels operated by international carriers into a global telecommunication network. 
12 

13 Although the PSTN telecommunication network was originally designed to cany analog 

14 I voice conraumications requiring only a bandwidth of about 4000 Hz for each conversation, 

15 I telecommunication carriers learned early in the history of telephony that significant cost savings could 

16 be achieved by combining several telephone conversations and transmitting them over a single 

17 I transmission channel, consisting of a single wire pair, for example. The process of combining multiple 

18 I information signals such as those in multiple telephone conversations is referred to as multiplexing, 

19 I while the process of recovering individual conversations fi-om a common carrier signal and directing 

20 I them to the proper destination telephone is called de-multiplexing. 

21 I While there are a variety of multiplexing and de-multiplexing techniques available, a 

22 I method which is presently used most widely in the teleconmiunications industry is called Time Division 

23 I Multiplexing (TDM). In TDM, analog information signals such as voice signals, are first digitized, i.e., 

24 I converted into a stream of ones and zeros, or bits. The digital bits are then placed on a carrier signal 

25 I such as an electrical current alternating at a firequency substantially greater than the maximxmi voice 

26 I frequency which is to be transmitted, or on a laser beam, for example. This is done by modulating the 

27 I carrier signal in unison with the sequential variations of ones and zeros in the information signal. 

28 I Modulation consists of varying a characteristic such as the amplitude or phase of the carrier signal in 
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unison with the variation in ones and zeros of the information signal. In Time Division Multiplexing, 
the string of ones or zeros, called Packets, representing a particular telephone conversation, are 
interleaved, "or time sequenced," with packets of bits representing another telephone conversation, and 
transmitted on a common carrier signal. At the receiving end of the carrier signal, the packets of data 
representing the various conversations are spUt off from the other packets, converted into analog signals 
representing an original voice signal, and directed to the proper destination telephone. 

Since PSTNs provide their typical subscribers with a telephone conmiunication charmel 
which has a bandwidth of 4 kHz, that channel may also be used to cany digital data signals, as long as 
the data bandwidth of the signals is within the allotted bandwidth. Thus, Modems 
(Modulators/Demodulators) are used to convert digital signals from telefacsimile machines and 
computers to packets of digital signals which may be transmitted over telephone lines. Accordingly, 
communications between individual computers and remote Internet sites are also routinely made over 
PSTN voice-quahty lines. However, as can be readily understood, transmission of large amounts of 
data over reasonable time periods is frequently required by even modest sized enterprises. Therefore, 
telecommunications companies have made available wire or optical fiber communication lines which 
have a much greater bandwidth than ordinary voice grade telephone lines. For example, it is possible 
to rent Tl lines having a bandwidth of 1.544 Mbps (Megabits per second) in the United States, and El 
hnes having a bandwidth of 2.048 Mbps in Europe. For enterprises requiring higher data transfer rates 
DSL (Digital Subscriber Lines) may be rented from the PSTNs, as can fiber optic lines having 
bandwidths ranging from several hundred Mbps, to several gigabits per second. 

Not surprisingly, higher bandwidth communication lines are rented by the PSTNs at 
correspondingly higher prices. Moreover, as the following discussion will illustrate, the bandwidth 
requirements of even modest enterprise conmiunications can be substantial. Thus, for example, a single 
voice grade digital telephone channel of the type connected to most residential telephones has a 
bandwidth of 64 Kbps (kilobits per record). This bandwidth requirement derives from the fact that 
ordinary voice communications, if they are to be transmitted with acceptable clari^ and caller 
recognizability, must have, as stated earlier, a bandwidth of 4Khz, if transmitted as an analog signal. 
However, as is well known, the Nyquist sampling criterion requires that an analog signal must be 
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1 H sampled at least twice the maximum frequency that is desired to reproduce. Accordingly, 4Khz voice 

2 signals must be sampled at 2X4Khz = 8Khz. Also, the dynamic range of voice signals required for 

3 acceptable communication has been deteraiined to be about 256 to one, or 8 binary bits. Therefore, each 

4 digitized telephone connection channel must have a bandwidth of 64 Kbps. Thus, a Tl line, which at 

5 first glance would appear to have a substantially high bandwidth relative to that required for analog 

6 telephone conversations, can transmit only 24 digitized, TDM voice signals. 

7 Li addition to requiring substantial commxmication bandwidths for even modest numbers 

8 I of telephone lines, most enterprises required substantially greater channel bandwidths for data 

9 I interchange between enterprise sites and/or the Internet. Moreover, the increased use of video 

10 teleconferencing between various enterprise facihties requires even greater bandwidths. Thus, each time 

1 1 I an additional group of telephones, new computer system, or video conferencing installation is added to 

12 an enterprise facility, it is generally required to procure additional communication lines from a PSTN 

13 service. This entails substantial capital investment and recurring costs, and the installation and 

14 I connection of the new lines can disrupt enterprise operations. 

15 I In recognition of the problems resulting from increased commxmication channel 

16 bandwidths required by the burgeoning use of telephone, data, image and video transmissions by various 

17 I enterprises, teleconmiunication experts have devised and implemented a mode of transmitting various 

18 signals of the foregoing type over a single communication channel. This technique is referred to as 

19 Asynchronous transfer Mode, 

20 To better understand ATM, and the novel advantages and benefits that the present 

21 I invention contributes to ATM communications, it is perhaps useful to consider briefly data 

22 conmiunication modes which preceded ATM. Thus, as described above, PSTN carriers transmit 

23 multiple voice signals over a single wire pair, optical fiber, satellite channel or the like, using time 

24 I division multiplexing. In this communication mode, groups of individual bits, or packets, representing 

25 I a single telephone conversation, for example, are interleaved in time with packets representing other 

26 I conversations, into a single serial data stream. Typically, eight bits of information are grouped together 

27 in a serially arranged string to form an 8-bit Byte. Packets of bytes are then grouped together into a 

28 Frame, which adds a group of coding bytes called a header at the beginning of a data stream. Among 
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other things, the header identifies the source and destination addresses of information or PAYLOAD 
bytes which follow the header, i.e., arrive later. The length of a fi-ame is not specified, but may be 
limited by a PSTN carrier to a maximum value, one thousand bytes, for example. 

Since the length of a Frame is indeterminate in some instances, a trailer mxist be placed 
at the end of each Frame, indicating that the inmiediately preceding byte was the last byte in a payload, 
and indicating source and destination addresses of the next packet of bytes. This method of grouping 
bytes together and identifying source and destination addresses, as well as other parameters related to 
the intended disposition of a data stream, is referred to as FRAME RELAY and is widely and effectively 
used in the telecommunication industry. 

By communicating information packets in Frame Relay Frames, computer files may be 
interleaved with telephone conversations and transmitted in the Frames. This interleaving may be 
optimized by utilizing Statistical Time Division Multiplexing (STDM). In STDM, pauses in certain 
communications which would normally be encoded into data packets that convey no information are 
replaced by data packets bearing usefiil information from another telephone conversation, computer data 
file or the like. The STDM technique works well enough vsdth Frame Relay for interleaving certain 
types of data traffic, such as telephone conversations and computer data files, because the unpredictable 
interruption and resumption of computer data transfer is usually of no concern, as long as all of the data 
bits eventually arrive at their destination at an acceptable overall or average data rate. However, other 
types of data may not readily be interleaved in a Frame Relay Frame. For example, while an occasional 
interruption of data flow, or variable delays in the arrival of data at a destination generally are not 
problematic in the transfer of computer data, such interruptions or delays can cause video images to tear 
or otherwise degrade in an unacceptable fashion. Also, voice conununications which are delayed more 
than about 100 mseconds can be a source of armoyance to persons engaged in a conversation, and CD 
quality, high fidelity sound is perceptibly degraded by delays or Latency Periods much greater than about 
100 microseconds. Thus, the disparate bandwidths and delay requirements of voice, digital data, video, 
image, and music are relatively hard to reconcile using Frame Relay Multiplexing of such signals, and 
this difficulty motivated, at least in part, the creation of the Asynchronous Transfer Mode (ATM). 
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In ATM, each packet of bits representing information is defined as a CELL which has 
a length fixed at 53 eight-bit bytes, or octets. The first 5 bytes of each cell comprise a header which 
contains, among other things, information related to the source and destination of the 48-byte-payload 
which immediately follows the header. Since each cell is exactly 53 bytes long, it is generally not 
necessary to have a trailer indicating the end of a payload. Also, the header of each ATM cell contains 
information related to which Virtual Channel (VC) within a Virtual Path (VP) that the cell is to travel. 
Moreover, the Virtual Chaimel and Virtual Path taken by each cell is specified by Virtual Path Identifier 
and Virtual Channel Identifier bits, respectively, in the header, causing the cell to travel over a channel 
specified to afford a particular Quality of Service (QoS), which will now be explained. 

There are presently five QoS categories in ATM, ranging from one accorded the highest 
network priority , for which a PSTN or other carrier generally charges the most, to the lowest network 
priority, which is generally the least costly. The highest QoS category is Constant Bit Rate (CBR), 
which is contracted for between a user and telecommunication carrier for sensitive applications 
requiring a constant throughput rate with minimal cell delays or loss. Applications requiring CBR 
include PCM (Pulse Code Modulated) data streams carrying real-time voice, video, and circuit 
emulation of private lines or other TDM circuits. The quality of service or QoS category having the 
second highest network priority is Variable Bit Rate-Real Time (VBR-RT) and is used for information 
which must be transmitted at a fairly predictable rate, and which is sensitive to delay and loss. 

QoS service categoty 3 is called Variable Bit-Rate, Non-Real Time (VBR-NRT), and is 
used for information which is less sensitive to delays. QoS category 4 is called Unspecified Bit Rate 
(UBR), and is used for applications in which substantial delay times are tolerable. QoS categoty 5 is 
called Available Bit Rate (ABR) and is used for transmitted information that is less critical than UBR 
data. 

ATM has proven to be a highly efficient data transmission protocol, and has therefore 
been adopted by PSTNs and other telecommunication carriers world-wide. These carriers have invested 
heavily in converting hardware and software systems which formerly could work only with the Frame 
Relay protocol, to systems in which ATM format signals can be Interworked, or transformed into Frame 
Relay signals, and vice versa. Computers used to direct ATM data streams to the proper destination 
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1 B along wires, optical fibers or microwave carrier signals between ground stations or satellites are called 

2 Switches, and an ATM network whole is referred to as an ATM Backbone. 

3 I Devices which interconnect two or more networks are referred to as Bridges. Routers 

4 I are devices which perform functions similar to those of Bridges, but function at a higher level. Thus, 

5 I while a bridge knows the addresses of all the computers on each network joined together by the bridge, 

6 I a Router also recognizes that other Bridges and Routers are on the network. Using that information, the 

7 I Router is able to decide the most efficient path to send each message between a pair of end users. ATM 

8 I networks may employ any of the devices described above. 

9 I A device of higher complexity than a Router exists, called a Gateway. The Gateway 

10 I performs functions similar to that of a Router. However, in addition to routing functions, a Gateway is 

1 1 I capable of translating or Interworking messages from one network format to the format of a different 

12 type of network. A Gateway can perform data format translations which enable data interchange 

13 I between a LAN, such as an Ethemet LAN, and an ATM Backbone Network. 

14 I For an enterprise to fully exploit the advantages offered by ATM in achieving the goals 

15 of streamlining its communications while minimizing costs, it is usually necessary to have equipment 

16 I on the enterprise site which enables the enterprise to connect its various systems to an ATM Backbone 

17 I network. Such systems may include TDM voice signals from a PBX, video conferencing signals, 

18 I Ethemet or other protocol LAN signals, among other types of data. ATM access equipment of this type 

19 I are customarily referred to as Customer Premises Equipment (CPE), owing to the location of the 

20 I equipment at an enterprise site. ATM CPEs provide a User to Network Interface (UNI), while 

2 1 I interconnections between various nodes of an ATM network are called Netware Node Interfaces NNI). 

22 j 

23 I There are presently available CPE devices which provide enterprises with access to an 
ATM Backbone network, thus allowing the enterprise to bundle its communications links, including 
voice, data, video and the like, onto a common communication channel. However, there are a number 
of problems with existing CPE devices affording ATM access. Such problems have limited the fiill 
utilization of the advantages offered by ATM. 
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Although problems associated with the enterprise utilization of ATM are diverse, a main 
source of problems is the inherent complexity involved in the segmentation of data cells received from 
a stream source, and the reassembly of cells from diverse downstream sources such as PBXs, LANs, 
video cameras and the like, into a single ATM cell stream. Thxis, while the stripping of different serial 
data flows from incoming ATM cells into individual data flow queues, and the interleaving of various 
outgoing cell queues into a single ATM cell stream may seem to be a relatively straight forward task, 
it in fact requires substantially great real-time computing power. Of course, if one had a super computer 
available which is dedicated to the task of performing ATM access fimctions such as those of a Router 
or Gateway, the computational portions of these task fiinctions may be readily performed. However, 
the various types of interfaces typically required of an ATM access device would still be problematic, 
even if the exorbitant cost of a super computer could be discounted. 

Becaxise of the inherent complexity involved in performing various functions required 
of ATM access devices, present devices fall into general categories: (1) Versatile and very expensive 
devices using raw, high speed computational power afforded by general pxirposes processors, and (2) 
Moderately priced devices having limited capabilities. 

The present invention was conceived of to provide an Integrated Access Device for 
Asynchronous Transfer Mode (ATM) Communications, which provides a wide variety of CPE UNI 
functions with substantially greater proficiency than existing devices, and at a substantially lower cost. 
The foregoing advantages are achieved by the novel combination of a RISC (Reduced Instruction Set) 
processor with a custom PLA (Progranmiable Logic Array) or ASIC (Application Specific Integrated 
Circuit) having a variety of performance enhancing imbedded algorithms. 

OBJECTS OF THE INVENTION 
An object of the present invention is to provide an Integrated Access Device For 
Asynchronous Transfer Mode (ATM) Information commimications, which provides bridging, routing, 
and interworking functions between ports selected from a group including ATM, Ethernet, Frame 
Relay, Voice, and Video signal technologies. 

Another object of the invention is to provide an Integrated Access Device for ATM v^ch 
converts incoming non-ATM signals to ATM signals, and imposes ATM QoS standards on the ATM 
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signals, thus allowing ATM QoS to be imposed on signals which may be inputted and outputted as non- 
ATM signals. 

Another object of the invention is to provide an Integrated Access Device for ATM v^ch 
provides ATM switching and scheduling utilizing a RISC microprocessor which is operably 
interconnected with a hardware programmed gate array so as to minimize computational and memory 
requirements of the microprocessor. 

Another object of the invention is to provide an Integrated Access Device for ATM which 
utilizes a microprocessor operatively interconnected with a Programmed Gate Array via a local bus, and 
a plurality of expansion ports connected to the programmed gate array via an expansion port bus, 
whereby input/ou^ut modules of various types may be plugged into any of the expansion ports. 

Another object of the invention is to provide an Integrated Access Device for ATM which 
utilizes a single fimctional block which serves as a scheduler to fiilly service multiple qualities of service 
(QoS). 

Another object of the invention is to provide an Integrated Access Device for ATM which 
contains a functional block that assigns a scheduler resource to multiple ports in correct proportions, 
with fine granularity in representing relative rates and intervals. 

Another object of the invention is to provide an Integrated Access Device for ATM which 
contains a functional block including a beaded buffer pointer chain with intermediate pointers, thereby 
enabling multiple processes queues to be combined into a single flow queue. 

Another object of the invention is to provide an Integrated Access Device for ATM which 
contains a fimctional block that provides capabilities of cut-through routing of data streams through the 
device. 

Another object of the invention is to provide an Integrated Access Device for ATM wiiich 
contains a functional block that provides multiple preemptive CBRs for Precise Port Pacing Control. 

Another object of the invention is to provide an Integrated Access Device for ATM that 
includes a functional block comprising a partitionable page shifter with self-timing XOR chain. 
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Another object of the inventioii is to provide an Integrated Access Device for ATM wdiich 
includes a fimctional block that provides cell output flow rates having fractional interval times for fine 
granularity bandwidth allocation. 

Various other objects and advantages of the present invention, and its most novel 
features, will become apparient to those skilled in the art by perxising the accompanying specification, 
drav^ngs and claims. 

It is to be understood that although the invention disclosed herein is fully capable of 
achieving the objects and providing the advantages described, the characteristics of the invention 
described herein are merely illustrative of the preferred embodiments. Accordingly, we do not intend 
that the scope of our exclusive rights and privileges in the invention be limited to details of the 
embodiments described. We do intend that equivalents, adaptations and modifications of the invention 
reasonably inferable from the description contained herein be included within the scope of the invention 
as defined by the appended claims. 

SUMMARY OF THE INVENTION 
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5 

The present invention is directed to an Integrated Access Device (IAD) supporting data 
and voice in the customer premise. The IAD is a 1U high chassis based product. A modular 
design will enable it to support several configurations. 

The IAD main board contains all the circuitry and connectors for both the IAD application 
10 and the Fraim-IBM application and can be used in either product. The IAD is designed so that 
the form factor of the IAD main board is identical to the form factor of the Fraim-IBM CPU 
board. 

The IAD is a functional bridge and IP router incorporating Ethemet, Frame Relay. ATM 
and voice technologies. With ATM switching and scheduling at its core, the IAD will fully 
15 support quality of service in ATM and be able to impose ATM QoS onto its non-ATM ports. It 
will support ATM PVC's and SVC's with UNI 3.0, 3.1 and 4.0 signaling. AAL-5 will be supported 
for data. The IAD will incorporate Frame Relay over ATM Interworking standards FRF,8 and 
FRF.5. AAL-1 and AAL-2 will be supported for voice. Both digital or analog voice will be 
supported. 

20 The IAD can be modularized as shown in Figure 1. The Main Board performs the core 

ATM switching and scheduling functions and Frame Relay to ATM Intenworking. The Voice 
Processor performs voice compression and conversion of TDM voice channels to AAL-1 or 
AAL-2. The other modules provide physical interfaces. 

The Main Board has four expansion ports that connect to IAD input/output modules. 

25 Three of these apply to the IAD application However, it can be supplied with fewer or more IAD 
input/output modules. 



The present Integrated Access Device (IAD) advances the state of the art with 
architecture that achieves unprecedented levels of performance and economy in the delivery of 
broadband services to branch and regional offices. Specifically, the IAD allows incumbent and 
competitive access providers to deliver REAL T1 multiservice access at a relatively low price. 

5 The IAD defines a new class of access CPE, which delivers high-end performance at 

pricing that enables carriers to broadly offer integrated services to the branch office market 
segment. This is possible because of the IAD architecture which is a protocol interworking 
hardware accelerator that enables new levels of multiservice network processing capability in 
an economical, scaleable architecture. 

10 The Challenge in Public and Private Networks 

The task of bringing multiservice access to branch and regional offices presents unique 
challenges for equipment manufacturers: 

1. Cost of access bandwidth and eauipment On a per-Mbps basis, low-speed access 
bandwidth is most expensive in the network because it has not benefited from 

15 technology investments like optical networking the WAN or gigabit Ethernet in the LAN. 

2. Limited bandwidth . The vast majority of branch offices are still served by cooper. 
Although DSL technologies have made tremendous strides in increasing the usable loop 
bandwidth, it remains limited to a few Mbps or less. 

3. Pnce sensitivity . Branch and regional office access is the most price sensitive 
20 networking segment. Even though these services are part of a large corporate IT 

budget, every dollar spent for branch access is multiplied by the number of branches in 
the corporate network, making price an important discriminator. 

4. Muitiole communication protocols and traffic tvoes . Branch office IADs must be able to 
intenrt^ork between many communication protocols: Frame Relay, Ethernet, ATM. 

25 Internet Protocol (IP), digital time-division multiplex (TDM) voice, analog voice. T1/E1, 

12 



and xDSL. The complex translation process between these different protocols requires 

significant processor capabilities. 
5. Limited networking ex pertise at end-user The typical small, branch or regional office 

has little or no in-house networking expertise. 
5 When the technical requirements placed on IADs - easily managed platform with 

support for multiple protocols, bandwidth maximizing capabilities and robust traffic management 
- are compared to the cost sensitivity of the branch office access market segment, it quickly 
becomes apparent that IADs present one of the most challenging design problems in 
networking. 

10 In the past, access service providers could choose between two types of IADs for 

service deployment: high-end. high-performance equipment designed to scale to OC12 
speeds, but not cost effective at T1 or muIti-T1 speeds; or low-end, low-cost microprocessor- 
based equipment that have difficulty operating at wire speed when faced with a random mix of 
protocols. 

15 A Better Solution 

The IAD hardware-based networking processing accelerator specifically addresses the 
needs of the branch office access marketplace. The IAD hardware-based network processing 
accelerator operates in conjunction with a cost-effective RISC processor. Microprocessors are 
very effective in performing configuration and management functions but not efficient with highly 

20 repetitive data fonA/arding functions. The IAD hardware-based accelerator serves as the data 
foHA^arding engine, resulting in a high performance partnership. However, because the 
hardware-based accelerator is optimized for the branch office access challenge, it remains a 
very cost-effective solution. 

At the core of the IAD hardware-based accelerator is an ATM switch and traffic shaper. 

25 This is surrounded by a protocol-intenA^orking machine, allowing the hardware-based 



accelerator to adapt any type of traffic (TDM. IP. or Frame Relay, for instance) to ATM, apply 
ATM quality of service (QoS) to the traffic, then adapt it back into any other protocol. In this 
way. the hardware-based accelerator can provide any data flow with robust ATM QoS, even if 
the flow enters and exits the IAD in some other protocol. 

The IAD performs various protocol tasks, like Ethernet bridging, IP routing, and Frame 
Re!ay-to-ATM interworking. while optimizing the traffic characteristics of the data flows. The 
tight coupling between the IAD hardware-based accelerator and the RISC processor also 
enables the IAD's performance to scale to meet the future needs of the branch office. The IAD 
applies ATM inverse multiplexing to aggregate several wideband links into a single braodband 
connection, allowing carriers to deliver more services over existing copper plant rather than 
waiting for a slow fiber build-out program. Alternative access providers (wireless local loop, 
point-to-point radio, digital cellular radio, etc.) can also take advantage of the IAD's IMA 
technology since it is transparent to the physical layer employed. 

To take advantage of this protocol flexibility, the IAD can be built as a modular chassis, 
allowing earners to customize the platform for their particular networks' and markets* needs, 
such as the following interfaces: Ethernet, synchronous serial, quad T1 ATM IMA, and digital 
T1 PBX interfaces. 

In the modern networked enterprise, information technology must reach the most 
remote corner of the enterprise - however, this must be achieved without a similar deployment 
of network support personnel. The AID has been designed to meet these goals, including 
comprehensive remote management that allows configuration, monitoring and control without a 
truck-roll or site visit. 

The IAD represents a major step forward in the provisioning of true broadband services 
to small, remote branch office locations. 
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For the customer, the IAD enables the realization of the tnje connected enterprise 
where discrimination based on location can become a thing of the past. 

For the service provider, it allows them to capture the super-valuable business 
broadband sen/ice mark opportunity, without having to wait for fiber deployment. 
5 For the alternative access provider, the IAD IMA technology, in combination with rapid- 

deployment wireless technologies, unlocks new opportunities. The IAD allows rapid capture of 
high-value business markets without the need for capital investment in fixed local loop 
transmission technologies. 

The IAD represents a step change in opportunity. It opens new horizons in broadband 
10 deployment to the very edge of the enterprise or network by using the infrastructure which is 
already sitting in the ground - across the nation and the world. 

Overview 

The IAD of the present invention is an Integrated Access Device (IAD). 

15 The IAD is a Customer Premises Equipment (CPE) solution that enables organizations 

to connect multiple branch offices economically to a multiservice ATM or Frame Relay Wide 
Area Network (WAN). It provides the means for branch end-users to combine their voice and 
data network connections on to a single low-speed network path, which can be more easily 
managed from the central headquarters. 

20. The IAD connects to the customer's existing data, voice, and video equipment and 

resides in the end-user's communications room or closet. It is a sophisticated, branch-office, 
multiservice platform that provides many additional key functions and benefits over other CPE 
devices such as Frame Relay Access Devices (FRADs) or Time Division Multiplexers (TDMs). 
The IAD can be configured as a host or CPE access device to provide: 

25 1 . Frame Relay to ATM intenA^orking; 
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2. Inverse Multiplexing over ATM (IMA) for up to 4 x E1/T1 lines; 

3. Variable Bit Rate voice adaptation using AAL2 protocols; 

4. Circuit Emulation Services using AAL1 protocols; 

5. Comprehensive support for voice compression modulations; 

5 6. Echo cancellation and silence suppression for AAL2 protocols; 

7. Attachment to digital PBX using E1/T1 interfaces; 

8. Analogue FXO (Foreign Exchange Office) and FXS (Foreign Exchange System) 
operation with Ground or Loop Start; 

9. E&M (Electrical and Mechanical tie line) support for Types 1, 2, and 5 (Immediate, 
10 Delay, and Wink); 

10. Support for voice, video, or data over single or multiple ISDN-BRI; 

11. IP routing and bridging over ATM; 

12. DHCP (Domain Host Configuration Protocol) and NAT (Network Address Translation) 
support; 

15 13. Comprehensive support for SNMP network management; 

14. Maximum of 4096 connections (FR DLCIs (Frame Relay Address), ATM VCs, etc.); 

15. ATM PCR (Peak Cell Rate), SCR (Sustained Cell Rate), and MBS (Maximum Burst 
Size) traffic shaping; 

16. ATM classes: CBR, VBR-rt. VBR-nrt, UBR and UBR+; 
20 17, ATM PVCs and SVCs; 

18. Per port pacing; 

19. Frame Relay QoS via DLCI : CI R; and 

20. Confonnance to ATM and Frame Relay fomm standards. 
Interworkinq Technoloqv 
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The IAD interworking solutions provide peer-to-peer connectivity between the IAD 
located in the branch offices and IADs located in the central or regional office locations. ATM or 
Frame Relay PVCs or are mapped according to networking requirements, which provide for a 
fully meshed configuration to exist between all IADs within a given Multiservice WAN. 
Inverse Multiplexing over ATM 

The IAD offers the capability of connecting up to 4 x 2Mbps circuits into a logical IMA 
group, thus allowing ATM PVCs or SVCs to utilize available bandwidth fully. In this mode, the 
IAD connects to the ATM WAN switch via multiple 1.5Mbps (T1) or 2Mbps (E1) leased lines. 
The adjacent ATM switch must be configured with an equal IMA facility to terminate the logical 
group prior to core network switching of cell traffic, or the IMA group can be carried intact 
across the WAN to another IAD for termination. 
Enhanced Voice Convergence 

The IAD supports the multiplexing of compressed voice channels via ATM Adaptation 
Layer 2 (AAL2) protocols into a single ATM PVC or SVC, thus maximizing ATM bandwidth 
optimization. Further bandwidth efficiencies are obtained through utilizing silence suppression 
algorithms and local comfort noise generation to eliminate unnecessary cell transmissions. 
Additionally, the IAD supports uncompressed voice channel transmission via AAL1 structured 
Circuit Emulation Services (CES) to an adjacent IAD or other vendor equipment. 
IP Routing and Bridging 

The IAD offers unparalleled perfonnance versus cost using its proprietary technology to 
perform frame to cell conversion and data fonA/arding in hardware. The IAD performs both local 
IP routing (RIPv1 & v2) and switching as well as ATM bridging using multi-protocol 
encapsulation techniques over AAL5 (RFC 1483 and RFC 1577 for Classical IP). The bridging 
function also, supports the Spanning Tree protocol. 
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Frame Rel ay to ATM Interworkina 

Local data connections are managed via the IAD's Frame Relay to ATM Intenworking 
function. This facility enables customers to retain their existing router hardware and software 
configurations to preserve access to legacy applications. The data connection operates up to 
2Mbps via a DB25 V.35X.21RS-530. or RS-449 interface. The interworking function supports 
either Network (FRF.5) or Service (FRF.8) Interworking in accordance with the Frame Relay 
Fonjm multi-protocol implementation agreements (RFC 1490 
ATM Classes of Service 

ATM PVCs and SVCsare fully supported to ATM UNI 3.0, 3.1. and 4.0 signaling. Quality 
of Service and traffic shaping per port is provided via VCC PCR. SCR. and MBS parameters. 
Service classes are supported via Adaptation Layers 1. 2, and 5 utilizing classes CBR. VBR-rt. 
VBR-nrt. UBR. and UBR+. 
Advance d Network Management 

The IAD provides extensive network management facilities via its internal SNMP agent 
and a supporting SNMP Network Management Application. A full range of functions is available 
to configure, monitor, and report upon network performance, configuration parameters, call 
management, fault management, and IP/Frame Relay network protocol statistics. 
The IAD Management 

Management of IAD is available through local and remote access to one or more IAD's 
via SNMP. The application is designed to provide the network management capabilities 
expected from enterprise or carrier-class customers. Network management is generally defined 
to encompass two main areas, namely Monitoring and Control. Preferably, the IAD 
management can be through Mariner Networks. Inc.. Anaheim. California. Messenger™. SNMP 
Network Management Application which can provide local and remote access to one or more of 
the IAD's. 
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Network Monitoring is concerned with observing and analyzing the status and behavior 
of its networi< domain configuration and its devices. 

Network Control is concerned with the altering of parameters of various configurations of 
the networi< devices and causing those components to perform predefined actions. 

In line with this concept. IAD is a fully managed ATM IAD. which supports the following 
key disciplines: 

1. Networi< Management, 

2. Traffic Management, 

3. Code Management. 

4. Security Management. 
Network Manaoemenf 

The IAD's subsystems can be managed in any of the following ways: 
From an ASCII terminal with a character-based command line interface that is directly 
connected to the console monitor port. 

By remotely logging into a command line interface via a Telnet session. This session 
may be via the local Ethernet port. Frame Relay port, or in-band across the ATM WAN. 

By accessing the IAD's SNMP Agent via an authorized network management station, 
such as a station running Mariner Networi<s' SNMP Management Application "Messenger. The 
network management station may reside anywhere in the network. 

The IAD's Messenger™ application can be run on any type of network management 
woricstatlon irrespective of operating system or machine type. It can be run under HP 
OpenView^ or independently, offering a complete network management environment for the 
enterprise or carrier class user. The graphical user interface (GUI) enables the operator to 
configure the IAD elements quickly and easily and to interrogate performance data and traffic 
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profiles in a variety of tables and charts. Multiple IAD configurations and maps may be viewed 
simultaneously. 

The IAD can support simultaneous access by multiple network management stations to 
facilitate redundancy and continuous network operational requirements. The SNMP agent can 
5 comprise Mariner Networks' Enterprise MIB and a number of industry compliant networking 
MIBs (ATM, FR, and MIB-II). 
Traffic Management 

The IAD's advanced traffic management functions include: 
1 . Priority queues per ATM Quality of Service (QoS), 
10 2. Constant Bit Rate (CBR), 

3. Real time Variable Bit Rate (VBR-rt), 

4. Non-real time Variable Bit Rate (VBR-nrt), 

5. Unspecified Bit Rate (UBR) 

6. Unspecified Bit Rate Plus (UBR+), and 

15 7. Traffic shaping per port and per Virtual Circuit (TM 4.0). 

The IAD ensures that the Virtual Channel Connection (VCC) contract is respected at the 
Virtual Channel (VC) level. To reduce irregular bursts of traffic, a reshaping function is provided. 
Code Management 

Code management allows the network administrator or network operator to manage the 
20 application and user configuration modules contained within the IAD. The application module 
contains the program logic necessary for the IAD to function. User configuration modules 
consist of parameters and network definitions that describe the network, voice characteristics, 
profiles, and packet/cell routing information. 

The IAD's flash memory can hold multiple copies of application modules as well as 
25 multiple copies of user configurations, and allows an operator to switch between them. In this 
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way, the IAD can be reloaded or re-configured to perfomn differently while still retaining the 
ability to recover from updates that fail to function as required. 

IAD's code management can be accessed in any of the following ways: 

1. Application and user configuration module data can be uploaded or downloaded using 
5 Tf=TP (Trival File Transfer Protocol). The IAD contains a TFTP server that enables bi- 
directional processes. 

2. Switching between application or user configuration data can be performed using either 
the console port via the command line interface (CLI), via a Telnet session, or remotely 
via the Management application. 

10 3. Using the console monitor port, uploading and downloading of application or user 
configuration data can be performed. 

Providing multiple copies of application and user configuration data in flash memory 
enhances the IAD's network manageability in a customer premises environment. The IAD's 
advanced network management capabilities enable network control and monitoring to be 
15 performed quickly and simply with the minimum of end-user involvement. 
Security Management 

The IAD can be configured with the following security features: 

Configuration Protection 

Access to the IAD via the console monitor port can be password protected to protect the 
20 IAD's configuration. This password can be changed at the customer's/end-user's discretion. A 
hardware-based reset feature can be incorporated to enable recovery to a default password in 
the event of password loss. 

Network Access Protection 

Telnet access to the IAD's Command Line Interface (CLI) via the ATM, local Ethernet or 
25 Frame Relay network is provided and access is controlled via a password. 
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Access to the IAD SNMP agent is controlled via a domain name to prevent and limit 
unauthorized use. 

Tvpical Implementations 

The IAD simplifies ATM access at the customer premises. This is achieved through 
implementing the IAD as an ATM Interworking Network Terminating Unit (NTU) that clearly 
defines the boundary of the ATM network from the customer's local network communications 
equipment. Through its ATM interworking capabilities, the IAD converges multiple services 
(voice, data, and video) over single or multiple upstream ATM links. Figure 2 illustrates a typical 
configuration. 

Figure 11 illustrates a simple "mesh system" implemented between several office 
locations. All IADs are configured to establish PVCs (Pemnanent Virtual Circuits) between 
remote locations and to the central location housing the host system and application servers. 
Multiple IADs may be installed at the central location to provide sufficient voice channel 
capacity for head office personnel. 

The IAD product can consist of a multi-slot, such as a 3-slot, chassis enclosure with the 
following components: 

1 . Main processor board with application software loaded. 

2. Power supply assembly, 

3. 1 X RJ45 Ethernet port, 

4. 1 X DB9 RS-232 console monitor port, and 

5. Three or more blank single-slot filler plates. 

The following components can be furnished with the IAD to facilitate power up and initial 
configuration: 
1 . Power supply cord, 
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2. RS232 modem cable, and 

3. Documentation CD-ROM package. 
System Component 

All IAD units are based upon a main processor board design and chassis enclosure that 
facilitates the insertion of one or more Network or User interface Modules depending upon the 
number of available slots. The modules are described below. 

The main processor board contains the CPU, various memory modules, operating 
system, and application code. Additionally, this board holds a switch processor, either a 
programmable logic device or an ASIC that performs frame to cell conversion and data 
forwarding in hardware. 

The IAD can be equipped with a single RJ45 socket on the front panel system unit to 
facilitate either lOBaseT Ethernet or Telnet management access. In this way, the IAD can be 
configured without the need for any modules to be inserted prior to use. Initial configuration of 
IP (Internet Protocol) addressing would need to be achieved via the console monitor port. 

The IAD is preferably equipped with the DB9 RS-232 female DCE connector unit to 
facilitate Initial configuration of the IAD unit. 

Main memory is provided in all IAD configurations. In addition to this memory offering, 
IAD is configured with flash memory to hold multiple application and user configuration data, 
and boot PROM to support initial power-on and program load functions. Sixteen (16) MB of 
DRAM memory can be used; more or less memory can be used. 

Each unit is preferably configured with an internal auto-detecting VAC power supply 
with a fused power switch and a power cord, 

A printed Quick Start Installation Guide is preferably provided with all IAD units. All other 
documentation relating to IAD is available on an accompanying CD-ROM or other memory 
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device or on a website. Additionally, all user-related documentation is available by downloading 
from the Mariner Networks website. 

Each IAD is fitted with a modem cable, such as an RS-232 DB9 DCE/DTE modem 
cable. Access to the console monitoring port is through a terminal device, such as a VT100 
terminal device. 

In addition to the base components supplied with the chassis, the IAD will need to be 
populated with one or more Network or User Interface Modules that connect the ATM WAN or 
the existing customer communications equipment. 

The IAD is preferably designed to be either a standalone, wall-mounted, or rack- 
mounted unit. Mounting kits can be made available to facilitate the installation of the IAD into a 
19 inch communications rack or onto a wall. 

A number of cabling options are preferably supported to accommodate connection of 
the ATM interface, and Frame Relay V.35/X.21 attached router to the IAD. 

The IAD can be supported by many types of network modules and user modules 
(Interfaces) which can be adapted to be received in universal slots, i.e. slots that will accept 
modules of any type of interface protocol, or dedicated slots that will receive a more limited 
number of modules of specific types of interfaces protocols. Universal slots are preferred. A 
limited number of network and user modules are identified in Table 1 . 
Network Module 

A 1 X port T1/E1 . or 4 X port T1/E1 module can be provided. 

Each module may be configured to operate in ATM cell delineation or Frame Relay 
HDLC delineation mode. Each interface can be presented as an RJ48C female socket that can 
accept either a T1 (1.5Mbps) or an El (2Mbps) facility interface. 

Each module can have the following characteristics: 
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1. 1 or 4 ports each operating at either 1.544Mbps or 2.048Mbps line rate. 

2. Each port may connect to an ATM switch via UNI (3.0, 3.1, or 4.0), or a Frame Relay 
DLCI compliant device. 

3. Integrated CSU/DSU functionality. 

5 4. Physical interface is electrical with impedance of 100/120 Ohms. 

5. One or more modules may be inserted into the IAD depending upon the available slots. 

6. Both modules are preferably easily swappable without the need for specialist knowledge 
or equipment. The IAD will probably require rebooting and reconfiguring upon change of 
module type. 

10 Figure 12 shows a 1 x port T1/E1 and 4 x port T1/E1 module face plates. 

Network Module 

A 4 X port El or T1 module for ATM Inverse Multiplexing over ATM (IMA) network can 
be provided. 

This module may be configured to operate in a variety of logical IMA line groups. Each 
15 interface can be presented as an RJ48C female socket that can accept either a T1 (1.5Mbps) 
or El (2Mbps) facility interface. 

The module has the following characteristics: 

1. 4 ports, each operating at either 1.544Mbps or 2.048Mbps line rate. 

2. Each port may connect to an ATM switch via UNI (User Network Interface) using a 
20 supported interface. 

3. T1 option has an integrated CSU/DSU (Channel Service Unit/Data Service Unit) 
functionality. 

4. Physical interface is electrical with impedance of 100/120 Ohms. 

5. One or more modules may be inserted into any of IAD's slots. 
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6. This module is preferably easily swappable without the need for specialist knowledge or 
equipment. IAD will probably require rebooting and reconfiguring upon change of module type. 

Figure 13 shows the faceplate of the module. 
Network Module 

A 1 X port DS-3 or 1 x port E3 network module for ATM DS-3/E3 network can be 
provided. 

Each module can be configured to operate in ATM cell delineation mode. Each interface 
is preferably presented as a BNC 75 Ohm female connector that can accept either a DS-3 
(45Mbps) or an E3 (34Mbps) facility interface. 

Each module preferably has the following characteristics: 

1. 1 port operating at 34Mbps or 45Mbps line rate. 

2. Each port may connect to an ATM switch via UNI using a supported interface. 

3. Physical interface is electrical with an impedance of 75 Ohms. 

4. One or more modules may be inserted into any of the IAD's slots depending upon 
availability. 

5. Both modules are preferably easily swappable without the need for specialist knowledge 
or equipment. IAD will probably require rebooting and reconfiguring upon change of 
module type. 

Figure 14 shows the faceplate of the module. 
Network Module 

A 1 X port OC-3 or 1 x port STM-1 for ATM 0C-3/STM-1 network can be provided. 

Each module is configured to operate in ATM cell delineation. The interface is presented 
as an optical fiber ST female connector that can accept either an OC-3 (155Mbps) or STM-1 
(155Mbps) facility interface. 
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The module has the following characteristics: 

1. 1 port operating at 155Mbps line rate software configurable between either the OC-3 or 
STM-1 format. 

2. Each port may connect to an ATM switch via UNI using a supported interface. 

3. Physical interface is single or multimode optical fiber. 

4. One or more modules may be inserted into any of IAD's slots depending upon 
availability. 

5. This module is easily swappable without the need for specialist knowledge or 
equipment. The IAD will probably require rebooting and reconfiguring upon change of 
module type. 

Figure 15 shows the faceplate of the module. 
Network Module 

A 2 X port SDSL network module for the SDSL network can be provided. 

The module may be configured to operate in ATM cell delineation or Frame Relay 
delineation mode. The module may be configured to communicate with another IAD, DSLAM or 
other Central Office (CO) equipment. The module can be configured as either a CO or CPE 
(Customer Premises Equipment) device. 

The module has the following characteristics: 

1. 2 ports operating in variable rate SDSL (symmetric Digital Subscriber Line) using 
Globspan s"!2B1Q X DSL chip set. SDSL data rates of 144kb/s. 272kb/s. 400kb/s. 
528kb/s, 784kb/s. 1040kb/s, 1168kb/x, 1552kb/s, 2064kb/s. and 2320kb/s are supported 
using 2B1Q line encoding data rates. 

2. Each port may connect to an ATM switch via UNI, or a Frame Relay compliant device. 

3. Physical interface Is electrical with impedance of 50/75 Ohms. The connectors are RJ1 1 
terminating voice grade telephone wire local loops. 
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4. One or more modules may be inserted into any of IAD's slots depending upon 
availability, 

5. This module is easily swappable without the need for specialist knowledge or 
equipment. IAD will probably require rebooting and reconfiguring upon change of 
module type. 

Figure 16 shows the faceplate of the module. 
Network Module 

A 1 X port ATM/FR for HDSL2 network can be provided. 

The module may be configured to operate in ATM cell delineation or Frame Relay 
delineation mode. The module may be configured to communicate with another IAD, DSLAM 
(Digital Subscriber Line Access Multiplexer), or other Central Office (CO) equipment. The 
module can be configured as either a CO or CPE device. 

The module has the following characteristics: 

1. 1 port operating up to 1 .5Mbps using 2B1Q line encoding data rates. 

2. The port may connect to an ATM switch via UNI, or a Frame Relay compliant device. 

3. Physical interface is electrical with impedance of 50/75 Ohms. The connector is RJ11 
terminating voice grade telephone wire local loops. 

4. One or more modules may be inserted into any of IAD's slots depending upon 
availability. 

5. This module is easily swappable without the need for specialist knowledge or 
equipment IAD will probably require rebooting and reconfiguring upon change of 
module type. 

Figure 17 shows the faceplate of the module. 
Port Module 
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A 1 X port user or network module for synchronous serial lines can be made available. 

The module is configured to operate in Frame Relay mode, clear channel or channelized 
mode, or ATM mode via clear channel. The module can attach to an existing Frame Relay 
router or other Frame Relay compliant device. The interface can be configured for either V.35 
or X.21 via an adapter cable.. 

The module has the following characteristics: 

1. 1x DB25 female DCE/DTE synchronous port supporting, RS-530, or RS-449. Data rate 
can be set from 64K to 8.192Mbps. full duplex operation, 

2. One or more modules may be inserted into any of IAD's slots depending upon 
availability. 

3. The module is easily swappable without the need for specialist knowledge or equipment. 
The IAD will probably require rebooting and reconfiguring upon change of module type. 
Figure 18 shows the faceplate of the product guide. 

User Module 

A 4 X port 10/100BaseT user module can be made available. 

The module is configured to attach to an existing Ethernet LAN via a hub or switch. 
Each RJ45 port is rate auto-sensing and provides either switching of Ethernet packets between 
IAD's LAN interfaces or routing/bridging via AAL5 encapsulation over the ATM WAN. 

The module has the following characteristics: 

1. 4 ports of 10/100BaseT for local Ethernet or Telnet management access. 

2. Spanning Tree protocol is supported. 

3. Each port is on its own segment. 

4. One or more modules may be inserted into any of IAD's slots depending upon 
availability. 
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5. The module is easily swappable without the need for specialist knowledge or equipnnent. 

IAD will probably require rebooting and reconfiguring upon change of module type. 

Figure 19 shows the faceplate of the module. 
User Module 

A 1 X port T1/E1 user module for voice T1/E1/PR1 can be made available. 

The module may be configured to operate in either T1 or E1 mode and connects to the 
customer's local PBX system. The module provides a T1/E1 trunk type interface that can 
support either 24 (T1) or 30 (E1) channels of voice throughput. PBX supported interface 
signaling includes either Robbed Bit (T1), CAS (E1). or ISDN PRI using Common Channel 
Signaling (CCS) to provide 23 (T1) and 30 (E1) bearer channels respectively for voice trunking. 
The module also contains the necessary Digital Signal Processors (DSPs) and logic to provide 
voice compression, silence suppression, echo cancellation. AAL1AAL2 processing, and packet 
to cell conversions. 

The module has the following characteristics: 

1. 1 port operating at either 1.544Mbps (T1) or 2.048Mbps (E1). The module can be 
ordered with support for 8, 16, 24, or 32 voice channels. These channels may be 
assigned to any time slot in the T1 or E1 . 

2. Signaling supported includes RBS, CAS (El) and ISDN PRI (CCS). 

3. Supported CCS signaling for ISDN PRI includes PRI Net5 User. PRI Net5 Network, and 
PRI QSIG. 

4. AAL1 voice processing in accordance with af-vtoa-0078.000. 

5. AAL2 voice processing in accordance with ITU-T 1.363.2. 

6. Voice processing includes G.711 (64K PCM). G.726 ADPCM. G.727 EADPCM, G.729 
CS-ACELP. G.729AB CS-ACELP. and G.723.1A. 
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7. Support for Fax Relay and voice-band signaling. 

8. Physical interface is an RJ45 electrical with impedance of 100/120 Ohms. 

9. One or more modules may be inserted into any of lAD*s slots depending upon 
availability. 

10. The module is easily swappable without the need for specialist knowledge or equipment. 
The IAD will probably require rebooting and reconfiguring upon change of module type. 
Figure 20 shows the faceplate of the module. 

User Module 

A 1 X port T1/E1 + 1 X port ISDN BRI user module for voice can be made available. 

The PBX T1/E1 facility interface operates identically as outlined for the previous user 
module. Additionally, this module incorporates an ISDN BRIport that provides for attachment to 
a videoconferencing codec (although it may be used with any ISDN BRI compliant device). 

The module has the following characteristics: 

1. 1 port operating at either 1.544Mbps (T1) or 2.048Mbps (El). The module can be 
ordered with support for 8, 16, 24, or 32 voice channels. 

2. Identical characteristics to that of the PBX E1/T1 module. 

3. 1 ISDN BRI port providing 2 x 64K bearer channels and 1 x 16K D channel. Both S/T 
and U interfaces are supported. 

4. One or more modules may be inserted into any of IAD's slots depending upon 
availability. 

5. The module is easily swappable without the need for specialist knowledge or equipment. 
The IAD will probably require rebooting and reconfiguring upon change of module type. 
Figure 21 shows the faceplate of the module. 

User Module 
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A 2 X port ISDN BRI or 3 x port ISDN BRI user module for integrated service digital 
network can be made available. 

This module is equipped with either a dual port or triple port ISDN BRI facility that 
supports S/T and U interfaces. Each port can be configured to support voice, fax, or voice-band 
data signals. Full voice processing is supported for compressed or uncompressed transmission 
across the ATM WAN. 

Each version of the module has the following characteristics: 

1. 2 or 3 ports providing ISDN BRI sen/ice. Each port supports 2 x 64K bearer channels 
and 1 X 16K D channel. Both S/T and U interfaces are supported. 

2. One or more modules may be inserted into any of IAD's slots depending upon 
availability. 

3. Both modules are easily swappable without the need for specialist knowledge or 
equipment, The IAD will require rebooting and reconfiguring upon change of module 
type. 

Figure 22 shows the faceplate of the module. 
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In one embodiment, the IAD comprises a main processing board that contains core 
memory, application code, and optional interface modules. A key element of this design is the 
ATM switch processor. 

The ATM switch processor consists of a cell switching fabric with segmentation and re- 
assembly processes and a cell forwarding architecture that includes a cell scheduler function. It 
contains the necessary logic and dynamic tables to translate between ATM VCs and Frame 
Relay DLCIs. Additionally, through its powerful scheduling ability, it supports current ATM and 
Frame Relay Quality of Service (QoS) attributes. The processor uses an on-board CPU to build 
and maintain its tables and routing information. 

The ATM switch processor's unique benefit is that once its tables have been defined, it 
converts, routes, and switches frames and cells effortlessly, in hardware, and releases the main 
CPU to perform other processor intensive tasks such as voice processing. Unlike other 
comparable CPE devices, this blend of technology enables the IAD to deliver the processing 
power and switching performance that would normally be found in larger and more expensive 
access units. 

The IAD's other key components are the following subsystems: 

1. ATM Processing, 

2. Voice Processing, 

3. Network Management. 

The ATM Processing subsystem provides the broadband services to IAD's applications. 
Overview 

ATM processing, frame to cell conversion and transmission of cells to the ATM network 
modules is performed by the ATM switch processor. 
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The following ATM Adaptation Layers (AAL) and associated service classes are 
supported: 
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AAL1 


Constant Bit Rate 


CBR 


AAL2 


Variable Bit Rate 


VBR-rt 
VBR-nt 


AAL5 


Unspecified Bit Rate 


UBR 
UBR+ 



Table 2. 
Supported AAL Protocols 

AAL1 Operation . This layer is used to support all switched or permanent 
uncompressed voice calls. Uncompressed voice traffic is either carried as a structured or basic 
Nx64K CES cell stream as defined in the af-vtoa-0078.000 interoperability specification. Circuit 
Emulation Services (v2). 

AAL2 Operation . This layer is used to support all switched compressed voice calls 
over the ATM network. All AAL2 voice traffic between a pair of IADs is multiplexed across a 
single ATM VC. 

AAL5 Operation . This layer is used to support all Frame Relay data frames and 
Internet data packets over the ATM network. 

Quality of Service . The IAD performs traffic shaping of its outgoing ATM cell flow in 
accordance with the relevant standard for Connection Traffic Descriptor that was negotiated 
with the ATM network. The relevant parameters used to specify unambiguously the conforming 
cells of the ATM connection are Peak Cell Rate (PCR). Sustainable Cell Rate (SCR), and 
Maximum Burst Size (MBS). IAD contains two leaky buckets to support its QoS scheduling. 

Inverse Multiplexing over ATM Interface . The IAD can be configured to accept 
2Mbps circuits via a 4-port E1/T1 IMA interface, which can be configured into two IMA logical 
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groups. Typically, ATM PVCs would utilize all available circuits in the IMA group to provide 
greater throughput. An outline flow of ATM cells through an IMA configuration is illustrated in 
Figure 23. Here, an ATM data stream is split across three individual physical links on a cell-by- 
cell basis in a "round-robin" effect. 
5 Frame Relav to ATM Operation . The IAD supports both Frame Relay to ATM 

"Network" and "Service" intenworking as defined by the Frame Relay Forum's Frame 
Relay/ATM Network and Service Interworking Implementation Agreements (FRF.5 and FRF.8 
respectively). 

Network Interworking . This function is responsible for forwarding frames between the 
10 Frame Relay interface and the ATM Data Subsystem. The IAD processes frames received from 
the Frame Relay interface as follows: 

1. De-multiplexed according to their DLCI. 

2. Stripped of their HDLC encapsulation headers. 

3. BECN (Backward Explicit Congestion Notification), FECN (Forward Explicit Congestion 
15 Notification), and DE (Disregard Eligibility) congestion and flow control indicators are 

mapped according to ATM EFCI (Explicit Fonward Congestion) and CLP (Cell Loss 
Priority) settings. 

4. Re-encapsulated in ATM AAL5 CPCS PDUs. 

5. Segmented and multiplexed over the UTOPIA (Universal Test and Operations Interface 
20 for ATM) cell interface according to the ATM VCC (Virtual Channel Connection). 

In the reverse direction, the ATM cell traffic is processed as follows: 

1. ATM AAL5 CPCS PDUs (Protocol Data Unit) reassembled from the UTOPIA cell 
interface. 

2. De-multiplexed according to the ATM VCC. 
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3. Stripped of their AAL5 encapsulation overhead bytes. 

4. ATM EFCI, DE congestion, and flow control indicators are mapped according to FR 
BECN, FECN, and DE settings. 

5. Multiplexed over the appropriate Frame Relay interface according to DLCI. 

Figure 24 illustrates Network interworking mapping performed between frames and 

celjs. 

The Servic e Interworking fFRF.8^ . This function is essentially the same as the 
previous network function, except that protocol conversion algorithms are applied to convert 
Frame Relay bridged or routed PDU to ATM bridged or routed PDUs. Frames received from the 
Frame Relay interface are processed as follows: 

1. De-multiplexed according to their DLCI. 

2. Stripped of their HDLC encapsulation headers. 

3. Network protocol encapsulation headers mapped from those specified in RFC 1490 (for 
Frame Relay) to those specified in RFC 1483 (for ATM). 

4. Re-encapsulated in ATM AAL5 CPCS PDUs. 

5. Segmented and multiplexed over the UTOPIA cell interface according to the ATM VCC. 
In the reverse direction, the IAD processes the ATM cell traffic as follows: 

1 . ATM AAL5 CPCS PDUs reassembled from the UTOPIA cell interface. 

2. De-multiplexed according to the ATM VCC. 

3. Stripped of their AAL5 encapsulation overhead bytes. 

4. Network protocol encapsulation headers mapped from those specified in RFC 1483 (for 
ATM) to those specified In RFC 1490 (for Frame Relay). 

5. Multiplexed over the appropriate Frame Relay interface according to DLCI. 

Figure 25 illustrates Service Intenworking mapping performed between frames and cells. 
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Ethernet Operation 

The IAD is assigned an IP address and subnet nnask to each network port (including 
ATM WAN ports). Services such as Domain Host Control Protocol (DHCP) and Network 
Address Translation (NAT) are supported. 

The IAD performs both local IP routing (RIPv1 & v2) and switching between its local and 
network ports. Bridging between a pair of IADs is achieved by using ATM bridging multi- 
protocol encapsulation techniques over AAL5 (RFC 1483) and Classical IP encapsulation 
(RFC1577). 

Other protocols built into the IAD IP stack include the following protocols: UDP, TCP, 
TFTP, SNMP, ARP, and ICMP. Telnet packets received from the local ports or via the network 
ports are converted to command strings and passed to the IAD's command line interface (CLI) 
for parsing. 

Domain Host Configuration Protocol 

The Dynamic Host Configuration Protocol's (DHCP) purpose is to enable individual . 
computers on an IP network to extract their configurations from a server (the 'DHCP server") or 
servers, and in particular, servers that have no exact infomiation about the individual computers 
until they request the information. The overall purpose of this is to reduce the work necessary to 
administer a large IP network. IAD contains a DHCP server function 

Network Address Translation (NAT) is used to translate one IP address to another. NAT 
can be used to allow multiple PCs to share a single Internet connection. It can also be used as 
a security tool by shielding the IP addresses of devices within the attached intranet. NAT can 
also be used for general IP address management by protecting the attached intranet from 
excessive address changes due to other network addressing constraints. 

Voice Processing . This subsystem provides the voice and video-oriented narrowband 
services to the IAD's applications. 
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This section describes the functional aspects of IAD's voice processing capabilities, the 
IAD's voice traffic across the ATM WAN is managed using a mixture of both AAL1 CBR 
connections and AAL2 VBR-rt connections. 

AAL1 is used to carry uncompressed voice channels and associated Robbed Bit or CAS 
signaling transparently, end-to-end. AAL2 is used in conjunction with a signaling and 
compression engine such as Mariner Networks' proprietary signaling and compression engine, 
to switch and carry packetized. compressed voice traffic end-to-end. The AAL type is software 
configurable on a trunk channel basis, and compression algorithm/ratio basis. 

The IAD utilizes structured Circuit Emulation Services (CES), nailed up circuits 
supporting Nx64K (uncompressed) between IADs, or between the IAD and other vendors' 
equipment supporting standards-based CES. While uncompressed CES-based connections are 
less efficient than compressed, AAL2 based connections, they offer the greatest benefit in 
terms of end-to-end voice quality and interoperability. 

Figure 26 illustrates some of the network interconnection scenarios that can be 
implemented using stnjctured circuit emulation with a IAD network. 

In Figure 26, each of the ATM PVCs shown (A, B, C) carries a fixed, constant bit rate 
stream of ATM cells. The cell payloads, formatted according to the rules specified in af-vtoa- 
0078.000, contain voice samples and robbed bit signaling infomnation for the trunk channels 
that the associated PVCs are configured to transport between the attached voice interfaces and 
the ATM network. 

A CES connection provides a "nailed-up" transport for TDM voice data and voice 
signaling, allowing geographically dispersed telephony endpoints to communicate transparently 
over the ATM network. 

Circuits can be configured for either "Basic Mode", meaning that trunk channels are 
transported without associated signaling, or CAS mode, meaning that CAS/robbed bit signaling 
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information is included in the cell payloads. The latter is useful for connecting non-PBX type 
equipment (e.g.. analog handsets) at one end to PBX/trunk terminating equipment at the other 
end (loop extension). 
Compressed Voice Services 

By using AAL2 VBR-rt ATM circuits in conjunction with IAD's compression and signaling 
software, IAD can more efficiently transport voice and fax traffic across the ATM WAN. 

AAL2 provides for the bandwidth-efficient transmission of low-rate, short, and variable 
packets in delay sensitive applications. ATM's VBR-rt services enable statistical multiplexing for 
the higher layer requirements demanded by voice applications, such as compression, silence 
detection/suppression, and idle channel removal. Additionally, in contrast to AAL1 (which has a 
fixed payload). AAL2 offers a variable payload within cells and across cells. 

Compression and signaling software, such as Mariner Networks* compression and 
signaling software, terminates the local signaling channels and provides inter-IAD proxy 
signaling over AAL5. This signaling provides for compressed calls that includes Robbed 
Bit/CAS modes, and out-of-band Common Channel Signaling (CCS) for a number of message 
oriented signaling protocols. 

The IAD support compressed calls with in-band signaling (Robbed Bit/CAS) for non- 
ISDN T1/E1 interfaces and the following CCS variants when IAD is configured for ISDN PR! 
mode: 

1. PRI Nets User Mode 

2. PRI Nets Network Mode 
3 PRI QSIG. 

Figure 27 illustrates some of the networi< interconnection scenarios that can be 
implemented using a network of IADs and voice compression and multiplexing technologies. 
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Figure 27 has the following key attributes: 

1. Any combination of AAL1 uncompressed and AAL2 compressed calls can be configured 
and carried by the IAD. 

2. In addition to an AAL2 VCC between a pair of IADs, an AAL5 signaling VCC is required 
5 to carry the IAD's signaling protocol for switched, compressed voice/fax calls, such as 

Mariner Networks' proprietary signaling protocol for switched, compressed voice/fax 
calls. 

3. Inter-IAD AAL2 compressed VCCs can be used to connect dissimilar PBX technologies 
(e.g., ISDN PR! using CCS to standard T1 using robbed bit signaling). 

10 4. The IAD can also support analog interfaces that directly interface to fax machines, 
emulating the functions of a PBX to the attached devices. 
Protocols and Standards Compliance 

The IAD implements a combination of both standards-based and non-standards-based 
software protocols. The following sections provide an overview of these protocols. 
15 AAL1 Protocol 

The IAD implements Nx64K structured mode CES over AAL1, as defined in af-vtoa- 
0078.000. The IAD is loaded with conventional software configurable, on a per-VCC basis, to 
run either Basic or CAS-mode CES for configured taink channels. Trunk channels carried via 
CES are transported In uncompressed. 64K PCM format. The IAD does not implement 
20 unstructured mode CES (as defined in af-vtoa-0078.000). nor does it implement SRTS clock 
recovery as defined for AAL1 transport by the ATM Fomm and ITU. 
AAL2 Protocol 

The IAD implements a software based AAL2 implementation that is proprietary. This 
implementation utilizes the "general framework and Common Part Sublayer (CPS)" of the AAL 
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type 2 defined in ITU-T Recommendation 1.363.2. Tlie associated cell payloads comprise 
compressed voice/fax data output by the IAD compression engine. 

It is preferred to implement standards-based software solutions wlierever possible to 
maximize interoperability opportunities. Once the standards for AAL2 signaling have been 
5 agreed and accepted, such solutions will preferably be implemented into IAD's AAL2 voice 
processing software. 
AAL5 Protocol 

The IAD Implements the ITU-T 1.363.5-compliant AAL5 UBR transport mechanisms 
widely deployed today. This service is used to convey IAD voice signaling messages in 
10 conjunction with AAL2-based voice traffic. 
Voice Compression 

Voice compression is performed by IAD's compression engine that consists of software 
logic and a number of Digital Signaling Processors (DSPs). The IAD can be configured to 
operate with a number, such as 4 DSPs. Each DSP can support the processing of numerous, 
15 such as 8, voice channels concurrently. The IAD can be configured to support any set of the 
following voice encoding techniques: 

1. G.711 PCM, 64Kbps 

2. G.726 ADPCM, rates 16, 24, 32, and 40Kbps 

3. G.727 EADPCM, rates 1 6, 24, 32, and 40Kbps 

20 4. G.729A CS-ACELP and G.729B CS-ACELP, 8kbps rate 

5. G.723.1A, rates 5.3 and 6.3Kbps. 

Proprietary Protocols 

As the ATM Forum and/or the ITU do not yet standardize signaling for AAL2, IAD's 

utilize the proprietary Helium™ signaling protocol to establish and tear down individual 
25 compressed voice calls. These calls are signaled using Robbed Bit/CAS/CCS modes on the 



facility side, and converted to/from the IAD's proprietary "0.931 -like" signaling protocol for 
managing inter-IAD call states. Conventional signaling protocol may be used. 
PBX Interface Mode 

The IAD can operate in one of three modes: North American T1. Standard El. and E1- 
5 based ETSI ISDN PRI. 

In T1 mode, narrowband signaling is via the AB bit transitions in robbed bit frames of the 
T1 Super Frame (SF) or Extended Super Frame (ESF) multiframe. In E1 (non PRI) mode, 
narrowband signaling is via CAS AB bit transitions in slot 16 of all frames in the El (FAS/CAS 
or FAS/CAS-CRC4) multiframe. In E1 PRI mode, nan-owband signaling is configurable as 
10 QSIG, PRI NETS User Side, or PRI NETS Switch Side, via CCS in timeslot 16 of all frames in 
the El (FAS/CAS or FAS/CAS-CRC4) multiframe. 
Trunk Channel Signaling 

IAD supports the following narrowband signaling protocols for trunk channel signaling. 
For each channel, one of the following may be selected as the signaling protocol: 
1S 1 . Foreign Exchange Station Loop Start or Ground Start 

2. Foreign Exchange Office Loop Start or Ground Start 

3. E&M Immediate Start 

4. E&M Delay Start 

5. E&M Wink Start. 

20 This operation is unavailable when the IAD is operating in PRI (Primary Rate Interface) 

mode. 

Voice Coding Profiles 

PCM (Pulse Code Modulation) voice samples from the PBX (Private Branch Exchange) 
Interface are switched through the IAD's on-board Digital Signaling Processors (DSPs), on a 
25 per-call basis, in order to perform the required compression, silence suppression, voice activity 
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detection, and echo cancellation processes. All DSPs (up to a maximum of 4) are loaded with 
the same image at power up, which supports the following protocols (on a per channel basis. 8 
channels per DSP): 

1. G.711 

2. G.729A and B 

3. G.726 

4. G.727 

5. Standard Fax relay. 

Configuration of the DSP feature set is achieved through the creation of "Voice Coding 
Profiles". A coding profile is a set of configuration parameters that is assigned to a compressed 
call. The information in the coding profile informs the DSP how to process and route the 
compressed call through the system. 

Coding profiles with common characteristics must be configured on both IAD peers in 
order for a call to be successfully placed between them. At the originating end, a coding profile 
is assigned to a destination telephone number. When a call request for a particular destination 
is received from the telephony interface at the originating end, the parameters from the 
associated coding profile are negotiated with the remote peer via the IAD*s proprietary signaling 
message elements. At the remote end, a coding profile will have been associated with the 
telephony destination through prior configuration. 

Common elements from the originating side's coding profile and the destination side's 
coding profile are then negotiated and converged upon (via signaling) to create the set of 
parameters used to configure the associated DSP voice channels at both ends. Once this 
process is completed, the voice call is considered active. 
Dial Plan Configuration 
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In addition to physical resource configuration (PBX mode. FXO, FXS, etc.). a dial plan 
that specifies how to route calls between IAD peers is required. The IAD maintains its own dial 
plan that contains the following information: 

1. Dialed digit timeouts and termination sequences. 
5 2. Narrowband hunt group definitions, 

3. Broadband hunt group definitions, and 

4. Fonwarding criteria. 

SNMP (Sample Network Management Protocol) 

Standard MIB (Management Information Base) support for the IAD includes: 
10 1. RFC 1406 Standard T1/E1 MIB, and 

2. Supplemental MIB supporting ANSI T1 .231 , 

Additionally, IAD is configured with its Enterprise MIB structure to facilitate the reporting 
of non-standard object elements such as ISDN PRI information. 
Network Management Processing 
15 this subsystem provides the facility to control and configure the IAD's different 

subsystems. 
Overview 

The Network Management Subsystem comprises four main components that enable a 
network operator to configure, control, report, and perform diagnostics upon the IAD. These 
20 elements are: 

1. Configuration Management, 

2. Connection Management, 

3. Fault Management, and 

4. Performance Management. 



Configuration Management 

This component provides functions to configure all aspects of the IAD's physical 
interfaces, signaling protocol parameters, and call control parameters. From a management 
perspective, this involves the following entities: 



1. 


General node configuration, 


2. 


E1/T1 port and subchannels, 


3. 


BRI-ISDN, lOBaseT, V.35 , and RS-232C ports. 


4. 


ATM , and IMA ports, 


5. 


Narrowband signaling, 


6. 


Inter-IAD communications, 


7. 


Voice coding profiles. 


8. 


Routing, narrowband, and broadband addressing tables, 


9. 


0AM segmentation end points table, 


10. 


Frame Relay and IP interworking tables, and 


11. 


CES configuration. 



Connection Management 

Connection Management is a set of functions that is used to track the various call or 
connection oriented entities and configuration of PVCs, including applications they support. 
From a node management perspective, this involves describing the details of: 

1. Active call connections between narrowband and broadband resources, 

2. Active broadband connections for the total system. 

3. PVCs created for the broadband entities, 

4. PVCs created for the nan-owband entities, and 

5. Call history information. 



45 



Fault Management 

Fault Management is a set of functions that enable the detection, isolation, and 
correction of abnormal operation of the telecommunications parts of the network and its 
environment. From a node perspective, this tracks the following entities: 

1 . Physical facility and port failures, 

2. . Call control failures, 

3. ATM 0AM cell loopback tests, and 

4. Sundry fault management and vendor-specific diagnostics. 
Performance Management 

Performance Management provides functions to evaluate and report upon the behavior 
of telecommunication/data equipment and the effectiveness of the overall network or network 
element. From a node management perspective, this involves general performance, traffic, and 
data collection routines against the following entities: 

1. Physical layer performance monitoring of all ports, 

2. Cell level performance monitoring, and 

3. ATM layer protocol and perfomnance monitoring. 



46 



standards Compliance 

The standards and compliance specifications relevant to IAD are. 
ANSI Documents 

1. T1.CBR-199X Draft - Broadband ISDN - ATM Adaptation Layer for Constant Bit Rate 
Services. Functionality and Specification. November 1992. 

2. T1. 102-1 993. Digital Hierarchy, Electrical Interfaces, December 1993. 

3. T1. 107-1 995, Digital Hierarchy, Formats Specifications, 1995. 

4. T1. 231 -1993, Digital Hierarchy, Layer 1 In-Service Digital Transmission Performance 
Monitoring, September 1993. 

5. T1 .403-1 995, Camer-to-Customer Installation. DS1 Metallic Interface, March 1995. 

6. T1 .408-1 990, Integrated Services Digital Network (ISDN) Primary Rate - Customer 
Installation Metallic Interfaces Layer 1 Specification, September 1990. 

7. T1.606, T1.606a, T1.606b Frame Relay Bearer Service, Architectural Framework and 
Service Description. ANSI, 1990. 

8. T1 .646-1995, Broadband ISDN. Physical Layer Specifications for User-Network 
Interfaces Including DS1/ATM. 1995. 

9. EIA/T1A-547. Network Channel Terminal Equipment for DS1 Service, March 1989. 
ATM/Frame Relay Forum Documents 

11 AF-VTOA-0078.000, Circuit Emulation Service Interoperability Specification. Version 
2.0, January 1997. 

12. The ATM Forum, af-vtoa-0089.000, "Voice and Telephony Over ATM - ATM Trunking 
using AAL1 for Narrowband Services Version 1.0", July 1997. 

13. The ATM Forum, af-phy-0086.000. "Inverse Multiplexing for ATM (IMA) Specification, 
Version 1.0. July 1997. 
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14. The ATM Forum, af-vtoa-01 13.000. "ATM Tainking using AAL2 for Narrowband 
Services". Version 1.0. Febmary 1999. 

15. UTOPIA, An ATM-PHY Interface Specification. Level 2. Version 0.95. June 1995. 
ATM User-Network-Interface Specification. Version 3.1. September 1994. ATM Forum. 

5 16. UTOPIA. An ATM-PHY Interface Specification, Level 2. Version 0.95. June 1995, ATM 
Forum. 

17. Network Working Group. RFC 1483. "Multiprotocol Encapsulation over ATM Adaptation 
Layer 5". 

18. FRF. 1.1, User-to-Network Implementation Agreement. 

10 19. FRF.3.1. Frame Relay Forum Multiprotocol Over Frame Relay. 

20. Frame Relay/ATM PVC Network intenft/orking Implementation Agreement. Document 
Number FRF.5. December 20. 1994. 

21. Frame Relay Forum. Frame Relay/ATM PVC Service Interworking Implementation 
Agreement, Document Number FRF.8, April 15, 1995. 

15 IETF 

22. RFC 1483 Multiprotocol Encapsulation Over AAL5. July 1993. 

23. RFC 1490 Multiprotocol Interconnect Over Frame Relay, July 1993. 

24. RFC1577 Classical IP and ARP over ATM. January 1994. 
ITU Documents 

20 25. ITU-T Recommendation G.168, Digital Network Echo Cancellers, April 1997. 

26. Draft new ITU-T Recommendation 1.363.2. B-ISDN ATM Adaptation Layer Type 2 
Specification. Febmary 1997. 

27. ITU-T Recommendation 1.362 B-ISDN ATM Adaptation Layer(AAL) Functional 
Description. 
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28. ITU-T Recommendation 1.363 B-ISDN ATM Adaptation Layer(AAL) Description. 

29. Recommendation G.703. Physical/Electrical Characteristics of Hierarchical Digital 
Interfaces, 1991. 

30. Recommendation G.704, Synchronous Frame Structures Used at Primary and 
5 Secondary Hierarchical Levels, 1991. 

31. Recommendation G.706. Frame Alignment and Cyclic Redundancy Check (CRC) 
Procedures Relating to Basic Frame Structures Defined in 

32. Recommendation G.704, 1991. 

33. Recommendation G.804, ATM Cell Mapping into Plesiochronous Digital Hierarchy 
10 (PDH), January 1993. 

34. Recommendation G.823, The Control of Jitter and Wander Within Digital Networks 
Which are Based on the 2048 kbit/s Hierarchy, 1993. 

Recommendation G.826, Enror Performance Parameters and Objectives for 
International, Constant Bit Rate Digital Paths at or above the Primary Rate, 1993. 
15 35. Recommendation G.832. Transport of SDH Elements on PDH Networks: Frame and 
Multiplexing Structures. 1993. 

36. Recommendation 1.233.1, Framework for providing additional packet mode bearer 
services, ITU-T. 1988. 

37. Recommendation 1.370, Congestion management for the ISDN Frame Relaying bearer 
20 service, ITU-T. 1988. 

38. Recommendation 1.431. Integrated Services Digital Network (ISDN) User-Network 
Interface, Primary Rate UNI Layer 1 Specification, March 1993. 

39. Recommendation 1.432, Broadband Integrated Services Digital Network (B-ISDN) User- 
Network Interface. Physical Layer Specification, March 1993. 
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40. Recommendation 1.610. Broadband Integrated Services Digital Network (B-ISDN) 
Operation and Maintenance, Principles and Functions, March 1993. 

41. Recommendation Q.922 ISDN Data Link Layer Specification for Frame Mode Bearer 
Services. 1992. 

5 42. ITU-T Recommendation Q.931. DSS1 - ISDN User-Network interface layer 3 

specifications for basic call control. 
43. Recommendation Q.933, Digital Subscriber Signaling System No. (DSS 1), Signaling 

For Frame Mode Basic Call Control, ITU-T. 1993. 

Other Related Documents 
10 44. EN50082-1 "Electromagnetic compatibility. Generic immunity standard. Part 1: 

Residential, commercial and light industry". EN 50082-1:1997 (or BS EN 50082- 

1:1998). 

45. ENV 50204 "Radiated electromagnetic field from digital radio telephones - Immunity 
test", ENV 50204:1995. 

15 46, lEC 61000-4-2 "Electromagnetic compatibility (EMC). Part 4-2: Testing and 
measurement techniques, Electrostatic discharge immunity test". lEC 61000-4-2 Consol. 
Ed. 1.1 (ind. ami). 1999-05. 

47. lEC 61000-4-3 "Electromagnetic compatibility (EMC). Part 4-3: Testing and 
measurement techniques, Radiated, radio-frequency, electromagnetic field immunity 

20 test". lEC 61000-4-3 - Consol. Ed. 1,1 (ind. ami), 1998-11. 

48. lEC 61000-4-4 "Electromagnetic compatibility (EMC). Part 4: Testing and measurement 
techniques, Section 4: Electrical fast transient/burst immunity test. Basic EMC 
Publication". lEC 61000-4-4 - Ed. 1.0. 1995-01. 

49. lEC 61000-4-5 "Electromagnetic compatibility (EMC), Part 4: Testing and measurement 
'*.5 techniques. Section 5: Surge Immunity test". lEC 61000-4-5 - Ed. 1.0. 1995-02. 
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lEC 61000-4-6 "Electromagnetic compatibility (EMC). Part 4: Testing and measurement 
techniques, Section 6: Immunity to conducted disturbances, induced by radio-frequency 
fields". lEC 61000-4-6 - Ed. 1.0. 1996-04. 

lEC 61000-4-8 "Electromagnetic compatibility (EMC). Part 4: Testing and measurement 
techniques. Section 8: Power frequency magnetic field immunity test. Basic EMC 
Publication". lEC 61000-4-8 - Ed. 1.0. 1993-06. 

lEC 61000-4-11 "Electromagnetic compatibility (EMC). Rart 4: Testing and measuring 
techniques, Section 11: Voltage dips, short interruptions and voltage variations immunity 
tests". lEC 61000-4-11 - Ed. 1.0. 1994-06. 

EN50081-1 "Electromagnetic compatibility, Generic emission standard. Part 1: 
Residential, commercial and light industry". EN 50081-1:1992. 

FCC Part 15 "RADIO FREQUENCY DEVICES". Downloaded October 1998. Federal 
Communications Commission, USA, 

EN55022 "Information technology equipment. Radio disturbance characteristics. Limits 
and methods of measurement", CISPR 22 - Ed. 3.0 - Bilingual, 1997-11, or EN 
55022:1998. 

EN 55014-1 "Electromagnetic compatibility. Requirements for household appliances, 
electric tools and similar apparatus. Part 1: Emission. Product family standard". EN 
5501 4-1 :1993/A2: 1999. 

EN 61000-3-2 "Electromagnetic compatibility (EMC). Part 3-2: Limits - Limits for 
harmonic current emissions (equipment input current up to and including 16A per 
phase)". EN 61 000-3-2: 1995/A2: 1998. 

EN 61000-3-3 "Electromagnetic compatibility (EMC), Part 3: Limits - Section 3: 
Limitation of voltage fluctuations and flicker in low-voltage supply systems for equipment 
with rated current up to 16 A". EN 61000-3-3:1995. 
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58.. IEC60950 "Safety of information technology equipment." lEC 60950 (1 999-04) (Ed.3). 

59. EN60950 "Safety of information technology equipment." EN 60950: 1992/A4: 1997. 

60. UL 1950 "Standard For Safety For Information Technology Equipment", UL 1950_3 third 
edition 1995. 

61. UL 1459 "Standard For Safety For Telephone Equipment", UL 1459 third edition 1995. 

62. . EN 41003 "Particular safety requirements for equipment to be connected to 

telecommunication networks". EN 41003:1998. 
Books 

63. Demystifying ATM/ADSL: Busby. Michael; Wordware Publishing, Inc.; 1998. 

64. QoS & Traffic Management in IP & ATM Networks; McDysan, David; McGraw-Hill; 2000. 

65. ATM Theory and Application : McDyson, David E. and Spohn, Darren L.; McGraw-Hill; 
1998. 

66. ATM for Dummies : Gadeck; Cathy and Heckart. Christine; IDG Books Worldwide, Inc.; 
1997, 

67. Networking for Dummies : Lowe, Doug; IDG Books Worldwide, Inc.; 1994. 

The above documents and books are incorporated by reference herein. 
Related websites include: www.atmforum.com; www.cis.ohio-state.edu/-jain/refs/atm- 
book.htm (extensive list of ATM network related books); 

www.networking.ibs.com/atm/atmover.html; //members.tripod.comZ-'Vbkurnar/atm.html 
(extensive lists of glossaries, acronyms, telecommunications associations, organizations and 
forums); www.marinernetworks.coml; www.dexteraccess.com. 
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BRIEF DESCRTPTIQN OF THF. DRAWINGS 

Figure 1 is a simplified, partly schematic perspective view of an Integrated Access Device 
For Asynchronous Transfer Mode (ATM) communications Interface Module according to the present 
invention 

Figure 2 is a top-level block diagram of the device of Figure 1, showing major components 

thereof. 

Figure 3 is a more detached block diagram of the device of Figure 1. 
Figure 4 is a schematic diagram showing software modules of the device of Figure 1. 
Figure 5 is a block diagram of a voice card module according to the present invention 
useable with the device of Figure 1. 

Figure 6 is a block diagrana of another embodiment of a voice card module according to 
the present invention and useable with the device of Figure 1. 

Figure 7 is a perspective view of the device of Figure 1 , showing three different modules 
according to the present invention plugged into three different expansion ports of the device. 

Figure 8 is a schematic view showing the device of Figure 1 interfaced with various 
networks and devices through its expansion port modules. 

Figure 9 is a perspective view of a Tl/El IMA Interface Module according to the present 
invention and useable with the device of Figure 1, that Module adapted to perfomi inverse multiplexing 
of up to four Tl/El data lines. 

Figure 10 is a perspective view of a Synchronous Serial Interface Module according to 
the present invention and useable with the device of Figure 1, that module adapted to receive data in 
either an ATM cell or fi-amed mode. 

Figure 1 1 is a schematic view similar to that of Figure 8, but showing additional networks 
and devices interfaced with the device of Figure 8. 

Figure 12 is a fi-ont panel view of an ATM/FR Tl/El Interface Module according to the 
present invention. 

Figure 13 is a firont panel view of an ATM/FR Tl/El IMA Interface Module according 
to the present invention. 
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Figure 14 is a front panel view of an ATM DS-3/E3 Interface Module according to the 
present invention. 

Figure 15 is a front panel view of an ATM 0C-3/STM-1 Interface Module according to 
the present invention. 

Figure 16 is a front panel view of an ATM/FR SDSL Interface Module according to the 
present invention. 

Figure 17 is a front panel view of an ATM/FR HDSL2 Interface Module according to the 
present invention. 

Figure 18 is a front panel view of an FR V.35/X.21 Interface Module according to the 
present invention. 

Figure 19 is a front panel view of Switched 10/100 Base T Interface Module according 
to the present invention. 

Figure 20 is a front panel view of a PBX Tl/El Interface Module according to the present 

invention. 

Figure 21 is a front panel view of a PBX Tl/El/PRI + BRI Interface Module according 
to the present invention. 

Figure 22 is a front panel view of a ISDN BRIInterface Module according to the present 

invention. 

Figure 23 is a diagrammatic view showing Inverse Multiplexing (IMA) logic flow 
implemented in the device of Figure 1. 

Figure 24 is a diagrammatic view showing network interworking mapping implemented 
in the device of Figure 1. 

Figure 25 is a diagrammatic view showing service interworking mapping implemented 
by the device of Figure 1. 

Figure 26 is a diagrammatic view showing the device of Figure 1 interfaced with various 
networks and PBXs to form CES-based voice connections. 

Figure 27 is a view similar to that of Figure 25, but showing AAL-2 based voice 

connections. 
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Figure 28A is a simpliiSed block diagram of an Application Specific Integrated Circxxit 
[ASIC) module comprising part of the device of Figure 1, which is operably interconnected with other 
components of the device. 

Figure 28B is a more detailed version of the block diagram of Figure 28A 

Figure 29 is a table showing contents of a bubble register associated with the ASIC of 



Figure 28. 



Figure 30 is a diagram showing the structure of the register of Figure 29. 

Figure 31 is a table showing the arrangement of port scheduling registers of the device 



of Figure 1. 



Figure 32 is a flow chart showing port scheduling of the device of Figure 1 . 
Figure 33 is a table illustrating operation of the port scheduling portion of the bubble table 
of the device of Figure 1. 

Figure 34 is a table illustrating operation of the scheduler table function of the device of 

Figure 1. 

Figure 35 is a flow chart illustrating a Ci (Coimection Index) activation process 
implemented by the device of Figure 1. 

Figure 36 is a diagrammatic view of data structures of the device of Figure 1. 
Figure 37 is a table indicating assignments of port numbers for the device of Figure 1. 
Figure 38 is a group of 4 tables illustrating logical organization of the apparatus of Figure 



1. 



Figure 1. 



Figure 39 is a table showing FIFO sizes for the device of Figure 1 . 
Figure 40 is a table showing the organization of an IN STAT register for the device of 

Figure 41 is a block diagrain of a Cell Pointer block of the device of Figure 1. 
Figure 42 is a block diagram of a Tdm Resolution block of the device of Figure 1 . 
Figure 43 is a block diagram showing a prior art scheduler for multiple qxialities of 



service. 
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Figure 44 is a block diagram showing a single scheduler to fiilly service multiple quaUties 
of servdce according to the present invention. 

Figure 45 is a flow chart showing prior art multiple queues associated with a buffer pool. 

Figure 46 is a flow chart showing a Beaded Buffer Pointer Chain With Mtermediate 
Pointers according to the present invention. 

Table 1 is a list of Interface Modules useable in the device of Figure 1. 
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DESCRIPTIQN OF THE PREFERRED EMBODIMENTS 

1. Overview: CProduct Specification MAKO-Dexter - 3000, pp. 1-6, Revised 1.0.0.) 

2. 2-Page Dexter 3000 Integrated Access Device Data Sheet. 

3. 1-page Dexter 3000 Interface Module, Tl and El IMA. 

4. 1-page Dexter 3000 Interface Module, Synchronous Serial. 

5. Product Guide 

a. Chapter 2. Introduction. 

b. Chapter 3. Features and components. 

c. Chapter 4. Functional description. 

d. Chapter 5. Standards compliance. 

e. 1-page index 

In the description of the invention titled "Integrated Access Device For Asynchronous 
Transfer Mode ATM Conmiunications" contained in this specification, the invention is 
sometimes referred to as a Dexter 3000 IAD (Integrated Access Device), or Dexter. The 
Integrated Access Device for ATM according to the present invention includes an 
integrated circuit module vsrhich comprises an array of logic gates and flip-flops which 
are interconnected to form a cell switching fabric. The cell svydtching fabric functions in 
cooperation with other components of the Integrated Access Device to segment and re- 
assemble cell queues, and includes a cell forwarding architecture that implements a cell 
scheduler fimction. This Integrated Circuit Module is preferably an Application Specific 
Litegrated Circuit (ASIC) but may optionally be a Programmable Logic Array (PLA). In 
this specification, the integrated circuit which contains the cell switching fabric is 
referred to interchangeably as MAKO or eXpedite™ processor. 
6. Operation of the Invention. 

(a) Product Specification MAKO 

(b) Scheduler High Level Infonnation. Pp. 1-15. 

(c) Further Identified Aspects of the Invention. 

1 . A Single Scheduler to Fully Service Multiple Qualities of Service. 
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2. Algorithm to Assign Scheduler Resources to Multiple Ports in Correct 
Proportions. 

3 . Beaded Buffer Pointer Chain With Intermediate Pointers. 

4. Fractional Interval Times for Fine Granularity Bandwidth Allocation 

5. Multiple Preemptive CBR' s for Precise Port Pacing Control. 

6. Partitionable Page Shifter With Self-Timing Xor Chain. 




Product Specification 
Mako-Dexter-3000 



Document number 
Revision 1.0.0 



1. Introduction 

1.1. Document Scope 

^^ItT!;' T"''' .the Mako-Dexter-3000. an Integrated Access Device (IAD) for Asynchronous 
Transfer Mode Commumcations according to the present bvention, supporting data and voice in the 
cu^omer prenuse. Mak^Dexter Device-3000 is a lU high chassis based product. A modular design enables 
It to support several configurations. 

1.2. Mako-Dexter-3000 Description 

Mako-Dexter-3000 is a functional bridge and IP router incorporating Ethernet Frame Relay ATM and 

^XrrZ'^J^Vi '° ^P^''^ ^™ onto its non-ATM ports. It supports aSi PVC 

L^iZ? T AAL-5 is supported for data. Mako-Dexter-3000 

^^Z IV n*''?: Interworking standards FRF.8 and FRF.5. AAL-1 and AAL-2 are 

Sotlo^ra^rfe^.^''''^""^^^^^'" 

Figure 1: Mako-Dexter-3000 

The Mako-Dexter-3000 is modularized as shown in figure 2. The Main Board performs the core AIM 
SAvitchmg and scheduUng fiinctions and Frame Relay to ATM Interworking. The Voice Processor performs 
voice compression and conversion of TDM voice channels to AAL-1 or AAL-2. The other modules provide 
physical inter&ces. 

Figure 2: Major Components 
The Main Board has three expansion ports that connect to IAD input/output modules. 

The first expansion port is for WAN access. It comiects to one of several possible daughter cards. One type 
of daughter card is a Tl/El LIU. The Tl/El LIU daughterboard provides up to 8 ports of Frame Relay over 
Tl^l. Manner LIMO's are another type of daughter card that can be attached. Mariner LIMO's are current 
products that provide 4xIMA Tl/El. DS3/E3 and 0C-3/STM-1 WAN interfaces. Other daughter cards 
mclude DSL and ISDN. DSL interfaces may be SDSL or ADSL. 

The second port is for LAN access. It connects to a single or to a quad 10/100 Ethernet module. 

The third port is for voice access. It comiects to a Voice Processor module. This module, in turn, comiects 
to either a digital voice interface module or an analog voice interfece module. The digital voice module 
provides one channelized Tl/El port. The analog voice module provides 12 analog ports 
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2.1. Main Board 



The Mako-Dexter=3000 Main Board is architected as shown in figure 3. 

Figure 3: Mako-Dexter-3000 Main Board Block Diagram 

J.^mo'^^crnSr Tv^'I i;^^'^ " "^""^ °" -•^^'^ ATMOS operating system 
fW?" rrSr^ ^? ^""^^f"^ ^ ™. DHCP. NAT, ATM signalin& encapsS^tion 

SSm ,nH 1"^ SNMP 16 MB of SdLaM is avaUaWe fo^ 

F^ JkTlS ^T^"'- "^"^ - compres^r^arif a 2 

fS 1^1: """^^ ^ "^^^'^^'^ *° SDRAH Flash and other peripheralsTa 

MSnrl^^lSt"'"^"^ ^".,"''- '"^'^^ connections is performed m the Mako. a proprietary 

^J^n^rSL^ d^S^7^J"!f^ .unp e„.ented in an M^Ta 20K400F, FPGA untU the design be<Le s2 
^d ^rZ^ration oft*? .^^^^^ " array/standard ceU ASIC. ATMOS perfo^s progra^S^^ 
?nR AM f r x>rf °P«™tes at 98 MHz and utiLes its own dedicat^ 

U^evd ?^^f "^^'^ Mako has 6 data inter^: 3 E2m TDuZZ'^T^ 

r^nHp -ST t . !"*?^'- ^« "»terf^<=«s Operate at 8.192 MHz in El mode and 6.176 MHz in Tl 
when th?WAS?\ "^"^ TDM interfaces are routed to the^ pJn 

when the WAN Port .s comiected to the Tl/El LIU daughter card or to the ISDN daughter card When Se 

[Sip^rt " '^'^'^^"^ "^^^ Utopia imerfece is routed to the 

^oJ^^ l ' °' T "'^ '° ^th the Voice Processor. For lower cost, the 

^liul^^^^'''"^^'^ " ' ^ "-'^ °f SDRAM rather tha^ via 

E^^^M^^ifrm fS^x? '^' ^'^^^ '^"""^ ®^ Switch to read and write the 1024 bit ID 

orer^!^^:t^nSToi' '"""^ """"^^^ ^"'^^"^ ^ Serial Number and 

rith^^itS ™' multiplexed under software control serve as CLI console for 

etther the Mam Board or the Voice Processor. A Tehet session wiU also serve as an alternate console. 

I^e'D^l^^frrlnr" ,• Tu f i^'^i^^r- «8nals from this HeUum block, including LED's 

are passed from the Helium through the LAN connector to the LAN board. 

Sc'Ile^™,*!!' ? ^P^^'"^"*^! » FPGA or other convenient technology. This glue 

ogic performs device decodes, buflfering and other details. It also contains a register that can be written by 

H^J T ? "^T"" ' ''""^ ^•'^ ^ *«"^te? on an 8 pair 1^ c^^^ 

ImO^d J^atL" assembly can be used to comiect these signals to a similar 8 p^ header on the 
frn^ th T*"^ ^° caixi is the smaU PC board that passes data signals 

p^u/tll^ttrroo"^ ^'^"^ ^ ^° - 

Figure 4 shows the software structure for the Main Board. 



Figure 4: Main Board Software Structure 
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The AIMOS kernel b the real time operating system core that manages and schedules software operatioa 
TnH7T • '""^ *° ^« ^OBase-T controUer of tl^'S^ 

^:Soi"o?t;f sirrr °" ^'^^-^ ^ ^•^^^ ^^^-^ - 

rrs?T?n'°'''^^^ ''u""' '"'"^^ ^ ^^"^ -temal node or the HeUum 

lOBase-T port .s passed by the Mako hardware to the LocPt Rev module in the for™ of ATM ceUs oZ 
cdls are processed and appropriate response ceUs passed to the LocPt Send module which^ the.^ 
the Mako hardware for forwarding to the network. 

moSe^lt'r'^'r ','''^"'1?° °" ^'^"^"^ ^° HeUum Bridging 

module. TTie Hehum Bndgmg module passes them to the Helium SAR which converts them to packets S 
they are sent out on the Helium lOBase-T port. P-^iseis. men 

Lnul t'T^tK^pTc "'1°'^ "''"^ "^'"^^^^ ^« SAR into packets and 

sent to the FR LMI. FR Signaling. ATM ILMI, ATM Signaling or IP modules as appropriate. 

L'df Jrrr • ''^'^-'^ P^'* to see if they are destined for the internal 

H^um S AR r • V '"""'"'^ °* "''^"t^ to ceUs by the 

Hehum SAR and presented to the HeUum Bridging module which passes them to the LocPt Send module 
which passes them to the Mako hardware which routes them to the appropriate network port. 

The IP module forwards packets upward for UDP. TCP or ICMP processing or forwarding to upper layers 
m the traditional manner of IP protocol stacks. Packets reaching Telnet are converted to command strings 
and passed to the CLI for parsing. The CLI can also receive command strings from the Serial Port Drivi 
The CLI passes parsed commands to the Control & Configuration module. Packets reaching the SMNP are 
also parsed and the resulting commands passed to the Control and Configuration module. The Control & 
Configuration module processes command, performing whatever action is appropriate, and returns response 
information the whichever module, i.e. CLI or SMNP. passed the command to it. CLI and SNMP. in turn, 
encode the responses appropriately into packets and pass the packets back down. Downward passing 
contmues until the responses are sent out to the appropriate network comiectioa 

2.2. Voice Processor 

S'sI^TS^ ^ gone through two iterations. The first was quicker to market but more costly than 
^thT^i? ^ ^ architecture of the current Dexter 2200, including the MPC860 procior 
with Its own operatmg system and protocol stacks and is called the -860VoiceC^" in this document The 

DSP s and routing of DSP data through otherwise umised time slots on the TDM highway This second 
wiui oittenng external connection options. 

^^on^^mxZf^" t"^: SSOVoiceCard with digital PBX option. A single Tl/El/ISDN PRI 
uZll c Jf "^PP*"^^- A Similar diagram could be imagined with analog POTs comiecrions. 
up to 4 analog connections will be supported. 
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Figure 5: 860VoiceCard Block Diagram 

Sn Boa^rJS V • p ^ ^f""* '""^"^ ^ '^^'^ ^ ""^J^- » too wUl toggle between the 

The Dml Port RAM provides . mailbox inteA* between tl,e Voice Processor and tl,e Main Board. 
^"XTS^^v^'l ""^ 'J' ™" "> *' •^C860 where it is convened to 

Fi^re 6 shows the architecture of the MakoVoiceCard with digital PBX optioa Up to two Tl/El/ISDN 

Figure 6: MakoVoiceCard Block Diagram 

?me1^r^te'??[?s'lt° "^""n^^^^ f ^ '''' ^DM highway has twice as many 

thoL toe ?oS on TOM^r °° ^^^^ unprocessed data from th^ 

data t^/S-l oJ ASrSff' ^li^°"8h the Voice Port. The Mako can then convert the 

S e^tivdv iie iJ^w?^ ^""^ °' P*"*^^ ^"'^^ to the network. 

fZT.fI' T P^Sram the DSP's to read voice streams from the mcomins 

irS Z frn^, ?hr^' !" ° """'^ The Mako on the Nfain Board can read 

processed data from these time slots, package it into AAL-2 ceU streams and forward it to the network. 

2.3. WAN Interface 

^Z'mi;^°°-'''' f °f ^'^"^ cards can be comiected. including the LIU used with 

Frami-IBM. Manner LIMO's and future ISDN and DSL modules. ^useawim 

2.4. LAN Interface 

Two configurations of Ethernet interfeces are provided. Each contains a Packet Processor ASIC that 
performs a table lookup translation between Ethernet Mac addresses and ATM VPWCI combinations and 
"^^Z^nL ?" "^'^ encapsulation over AAL-5 conversioa One configuration supports a 

smgle 10/100 Ethenet connection. The other switches between 4 local ports and the Main Board 
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2.4, LAN Interface 

Two configurations of Ethernet interfiaces are provided Each contains a Packet Processor ASIC that 
perfonns a table lookiq> translation between Ethernet Mac addresses and ATM VPWCI combinations and 
perform RFC 1483 and RFC 1577 enc^sulation over AAL-5 conversion. One configuration supports a 
single 10/100 Ethenet connection. The other switches between 4 local ports and the Main Board. 
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Mufffsenrice Convergence 
Applfcafions oncf Customers 

• Healthcare — Telemedicine 

• Education - Distance Learning 

• Finance 
•Retail 

• International, National, and Regional 
Service Providers 

• ILECs, CLECs, ISPs, ICPs 

• Military Command/Field Communications 

• Local, Regional/State, National Government 

• Corporate offices 

• Utilities 




Key Benettfs 

■ Reduces equipment and line rental costs through the 
consolidation of separate voice, data, and video circuits 
onto a single cost-efFective, low-speed ATM path. 

■ Reduces monthly access service costs by maximizing 
bandwidth cfiBciency through intelligent, fine-grain con- 
trol over trafGc flows. 

M Improves small- to medium-sized ofiSce productivity 
by enabling corporate-centric applications, such as video 
distance learning or company board-level broadcasts, to be 
accessed easily and economically. 

H Rnhancfs interoffice communications by allowing 
offices and branches to become an intrinsic part of the 
corporate VPN without the need for cosdy access switches 
and high-speed communication lines. 

M Simplifies network management monitoring and 
reporting processes through reduced conununications 
eqmpment and a single networking topology. 

■ Provides an economical bandwidth growth strategy by 
applying ATM inverse multiplexing technology while 
mainta i ning wire-speed performance. 



The Mariner Networks Dexter® 3000 
Integrated Access Device (IAD) offers a 
fully scalable, easily affordable/ low- 
speed/ branch-office-access solution that 
enables companies to extend their ATM 
core network to all remote locations. It 
enables access to the broadband ATM 
backbone from existing legacy equipment 
without costly upgrades. 



Overview 

The Dexter produa family is a series of modular integrated 
access devices (IADs) that enable small and medium- 
sized offices to connect to integrated broadband 
services. The 3000 platform is the most 

high-performance, cost-cfFcctivc, mul- 
tiservice access platform available 
for connccung all of the 
office's voice, data, and video 
networking equipment to 
low-speed, scalable, wide-area 
network services. Its modu- 
scalable design allows the customer to 
specify only those features required to meet cur- 
rent needs but maintain flexibility for future growth. 

Bandwidth use on low-speed access links must be carefully 
managed to maximize the utility of this scarce resource. Based 
on Mariner Networks' proprietary cS^Jcdite™ technology, the 
Dexter 3000 uses fine-grained ATM scheduling to get the most 
out of this finite resource. 

The eXpedite architecture allows network managers to prior- 
itize traffic flows across their WAN. For example, e-mail flows 
will not interfere with voice traffic, just as real-time transaction 
data will not be delayed by Web siufers. 

The Dexter 3000 can also grow with the needs of the busi- 
ness by scaling up to four Tls or Els of inverse-multiplexed 
ATM, whUc maintaining wire-speed bridging, routing, and 
interworking. 

The Dexter femily of multiservice IADs offer high-quality, 
low-bandwidth, branch and regional office access solutions 
designed to address the needs of the small office through to the 
central headquarters. Through Dexter's highly versatile modular 
approach, every access solution requiring the efficient conver- 
gence of voice, data, and video into a single managed commu- 
nications link can be accommodated cost-cflFectively and simply. 
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Spedfications subject to (hcnge mihout notke 





The Dexter 3000's performance, ecottomyr and YersatiBty aBow network 
operators to deploy mhiservke access In a broad array of appBeations. 




An OtfvUu Compsny 



The Company 

Mariner Networks, Inc, a wholly owned subsidiary of Odettes, Inc., 
•"•tnufecturcs components and complete solutions for the ATM Wide 
.Networking communities and branch-officc-acccss applications, 
me compaa/s products include ATM subsystems, Frame Relay to 
ATM Incerworking and ATM access concentrators for handling voice, 
data, and video trafHc Mariner supplies equipment to many OEMs 
and end users through offices located in the US, Europe, and Asia. 



Dextef 30( 1 

Integrated Access Device 




Mocfufe-Enobleci Feofures 

• Integrated multiservice access device chat provides PBX 
voice, Frame Relay, Ethernet, Tl/El, IMA, multiple ATM 
and xDSL interfaces, and BRI video and data services 

• Frame Relay to ATM interworidng 

• AAL2 voice multiplexing vnxh VBR-rt QpS 

• Industry compliant silence suppression, comfort noise 
insertion, compression, and echo cancellation techniques 

• Circuit Emulation Services via AALl 

• Wire-speed IP bridging and routing 

• Local and remote management via 
Dexter's Messenger™ SNMP application 

• Compliant vnth industry-standard protocols 
and interfaces 

Technicaf Description 

• 3 -slot chassis - any module in any slot 

• Ethernet lOBaseT port 

• RS-232 DB9 management port 

• Dexter cXpedite"~ processor providing: 

• Layer 3 wire-speed switching 

• Frame Relay to ATM interworking (FRF.5 and FRF.8) 

• Frame Relay LMI to TL617 annex D and Q,933 armex A 

• Spanning Tree 

• RFC 1483 bridged and routed IP 

• NAT and DHCP server functions 

• Static routing via RIPvl and v2 

• ATM UNI 3.0, 3.1, and 4.0 

• ATM AAL5 adaptation 

• ATM PVC and SVC 

• ATM scheduler for end to end QoS 

• PPP over ATM 

• LANE Emulation Server vl.O 

• Telnet access 

• Configuration protected via password 
•SNMP Version 1. MIB n 

iMechonicof 

Size: 19" W x 12" D x 1.75 H (lU) 
Weight: 6.5ibs 
Mounting configurations: 

• Desktop, rack, wall-mount 

• 90-265 VAC 50/60HZ 

• Max power. 40W 

• 0" - 50** C operating temperature 

• Humidity: 5% - 90%, non-condensing 



1585 South Manchester Avenue 
Anaheim, CA 92802-2907 
Tel 714-780-7685 
ToUfhre 888-329-4487 
Sales 714-780-7987 
Fax 714-780-7696 
E-mail saies@marinemetworks.com www.dexteraccess.com 
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Dextef 3000 

InfeHute Module 

T1 and El IMA 




Key Features 

• Module operates in Inverse Multiplexing over ATM 
(IMA) mode. Supports one or two logical IMA 
groups. Single group can consist of up to 4 ports 
(up to 8Mbps in a single ATM VC in El mode) 

• Operates in either Tl (1.544Mbps) or El (2.048Mbps) 

• Ungrouped links operate as standard Tls or Els 

• Balanced 100/120 Ohm physical interface 

• ATMF UNI 3.0/3.1 

• Integrated CSU/DSU functionality 

• Multiple modules may be inserted into a single 
Dexter® chassis 

rnfrerfucffOff 

The Tl/El IMA Interface Module provides connectivity of 
up to 4 X 2Mbps circuits into a single logical IMA group 
thus allowing ATM PVCs or SVCs to utilize all available 
bandwidth within the group. The module enables connectivi- 
ty between the Dexter® family of Integrated Access" Devices 
(IADs) or other ATM IMA compUant vendor equipment. 

When used in the Dexter 3000 platform, the user can access 
the powerful functionality of the eXpedite™ architecture: 
converged voice, video, and data wide-area network access; 
wire speed protocol interworking, IP routing and bridging- ' 
ATM quality of service for all data flows; and much more! 

Key BenetHs 

• IMA technology enables scalable Tl or El bandwidth on 
demand without needing to jump to DS-3 or E3 circuits 

• Enables organizations to maximize available bandwidth as 
business volumes grow 

• Allows carriers to maximize utility of existing copper 
loop assets 

• Lowers the cost of ownership through by optimizing 
networic resources efficiently and simply 




Speciffcafiens 

CSU/DSU Function 

• Connector: 

• Bit rate: 

• Line Coding: 

• Clock source: 

• Impedance: 

• Framing: 

• Line Build Out: 



RJ48C 

1.544Mbps or 2.048Mbps 
B8ZS or HDB3 
Internal or external 
100/120Ohms 

D4(SF)orESF,FAS,CRC4 
0-133ft, 133-266ft. 266-399ft, 
399-533ft, 533-655ft, 
0db.-7.5db, -15db,-22.5db 



IMA Function 

• Supports 2 logical IMA groups 

• Passthrough mode for ungrouped links 

• Perfonnance and status reporting 

• Automatic detection and recovery from circuit failure 

Standards 

• ATMF: UNI 3. 1 , AF-PHY-0016, AF-PHY-0064, and 
AF-PHY 00086.000d 

• ANSI: Tl .102, Tl .107, Tl .23 1, Tl .403, Tl .408. 
T1.646, EIA/nA-547 

• ITU-T: G.703!, G.704. G.706, G.804. G.823, 
G.826, G.832, 1.431, L432, 1.610 

• ETSI: ETS 300 166, ETS 300 167, ETS 300 213, 
ETS 300 247, ETS 300 248, ETS 300 299. ETS 300 
337. ETS 300 418. ETS 300 419, ETS 300 420 
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Dextef 3000 

Interfate Module 

Synchronous Serial 




Key Fetifures 

• Single port, up to 8Mbps full duplex bit rate 

• Operates in either ATM cell or Framed mode 

• Frame Relay service interface supporting FRF.5 and 
FRF.8 FR/ATM interworking 

• DB25 physical interface 

• Cable adapter options are available that provide 
common physical interface connectors such as V.35 
X.21, RS.449, and RS-530 

• Multiple modules may be inserted into a single 
Dexter® chassis 



fnfrorfucffon 

The Synchronous Serial Interface Module provides connec- 
tivity between the Dextei^ family of Integrated Access 
Devices (IADs) and other ATM or Frame Relay compliant 
devices via a variety of cable connection interfaces. This 
module can be used to support legacy equipment such as 
Frame Relay routers and other framed mode equipment. 

When used in the Dexter 3000 platform, the user can access 
the powerful functionality of the eXpedite™ architecture: 
converged voice, video, and data wide-area network access; 
■wire speed protocol interworking, IP routing and bridging; ' 
ATM quality of service for all data flows; and much more! 

Key BenefiH 

• Enables customers to connect existing router and legacy 
equipment to a Frame Relay or ATM multiservice 
network without modification 

• Allows connection of an ATM cell stream across clear 
channel circuits to be attached to ATM cell-switched 
networks without modification 

• Provides a simple and cost-effective solution for 
Frame Relay across ATM transport services 




Specfffcafions 

Facility Interface 

• Connector: 

• Bit rate: 

• Framing: 

• Line coding, 

Frame Relay Mode: 

• Clock source: 

• Signal format: 



DB25 

Configurable between 64Kbps 
and 8Mbps 

ATM cell or framed 



HDLC 

Internal or external 
RS-232, V.35, X.21 



Frame Relay 

•LMITl .617 Annex D 
•LMI Q.933 Annex A 

• IP over Frame Relay per RFC 1490, Network and Service 
Interworking (FRF.5 and FRF.8) 

Standards 

• Electrical: EIA 530. V.35. X.21. RS-232 

• Physical: EIA-530 DCE 
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Chapter 2 



Introduction 



This section introduces the Dexter product and describes its 
principal functions and capabilities. 



Dexter Overview 

The Mariner Networks Dexter 3000 is a series of Integrated 
Access Devices (IADs), and fonms part of the family of Dexter 
IADs and access concentrator communications products. . 

Dexter is a Customer Premises Equipment (CPE) solution that 
enables organizations to connect multiple branch offices 
economically to a multiservice ATM or Frame Relay Wide Area 
Network (WAN). It provides the means for branch end-users to 
combine their voice and data network connections on to a single 
low-speed network path, which can be more easily managed from 
the central headquarters. 

Dexter connects to the customer's existing data, voice, and video 
equipment and resides in the end-user's communications room or 
closet. It is a sophisticated, branch-office, multiservice platform 
that provides many additional key functions and benefits over 
other CPE devices such as Frame Relay Access Devices 
(FRADs) or Time Division Multiplexers (TDMs). 

Dexter can be configured as a host or CPE access device to 
provide: 

• Frame Relay to ATM interworking 

• Inverse Multiplexing over ATM (IMA) for up to 4 x E1/T1 lines 

• Variable Bit Rate voice adaptation using AAL2 protocols 

• Circuit Emulation Services using AAL1 protocols 



Comprehensive support for voice compression modulations 



Echo cancellation and silence suppression for AAL2 protocols 

Attachment to digital PBX using E1/T1 interfaces 

Analogue FXO and FXS operation with Ground or Loop Start 

E&M support for Types 1, 2, and 5 (Immediate. Delay, and Wink) 

Support for voice, video, or data over single or multiple ISDN-BRI 

IP routing and bridging over ATM 

DHCP and NAT support 

Comprehensive support for SNMP network management 

Maximum of 4096 connections (FR DLCIs. ATM VCs, etc.) 

ATM PCR. SCR. and MBS traffic shaping 

ATM classes: CBR. VBR-rt. VBR-nrt. UBR and UBR+ 

ATM PVCs and SVCs 

Per port pacing 

Frame Relay QoS via DLCI : CIR 

Conformance to ATM and Frame Relay forum standards. 



Figure 1 Dexter front panel view 



Characteristics 

Dexter has the following characteristics: 

Interworking Technology 

Dexter intenworking solutions provide peer-to-peer connectivity 
between Dexters located in the branch offices and Dexters 
located in the central or regional office locations. ATM or Frame 
Relay PVCs or are mapped according to networking 
requirements, which provide for a fully meshed configuration to 
exist between all Dexters within a given Multiservice WAN. 



Inverse Multiplexing over ATM 



Dexter offers the capability of connecting up to 4 x 2Mbps circuits 
into a logical IMA group, thus allowing ATM PVCs or SVCs to 
utilize available bandwidth fully. In this mode, Dexter connects to 
the ATM WAN swrtch via multiple 1.5Mbps (T1) or 2Mbps (E1) 
leased lines. The adjacent ATM switch must be configured with an 
equal IMA facility to terminate the logical group prior to core 
network switching of cell traffic, or the IMA group can be carried 
intact across the WAN to another Dexter for termination. 

Enhanced Voice Convergence 

Dexter supports the multiplexing of compressed voice channels 
via ATM Adaptation Layer 2 (AAL2) protocols into a single ATM 
PVC or SVC. thus maximizing ATM bandwidth optimization. 
Further bandwidth efficiencies are obtained through utilizing 
silence suppression algorithms and local comfort noise generation 
to eliminate unnecessary cell transmissions. Additionally. Dexter 
supports uncompressed voice channel transmission via AAL1 
structured Circuit Emulation Services (CES) to an adjacent Dexter 
or other vendor equipment. 

IP Routing and Bridging 

Dexter offers unparalleled performance versus cost using its 
proprietary technology to perform frame to cell conversion and 
data forwarding in hardware. Dexter performs both local IP routing 
(RIPv1 & v2) and switching as well as ATM bridging using multi- 
protocol encapsulation techniques over AAL5 (RFC 1483 and 
RFC 1577 for Classical IP). The bridging function also supports 
the Spanning Tree protocol. 

Frame Relay to ATM Interworking 

Local data connections are managed via Dexter's Frame Relay to 
ATM IntenA/orking function. This facility enables customers to 
retain their existing router hardware and software configurations to 
preserve access to legacy applications. The data connection 
operates up to 2Mbps via a DB25 V.35X.21RS-530. or RS-449 
interface. The interworicing function supports either Network 
(FRF.5) or Service (FRF.8) Interworking in accordance with the 
Frame Relay Forum multi-protocol implementation agreements 
(RFC 1490 

ATM Classes of Service 

ATM PVCs and SVCsare fully supported to ATM UNI 3.0, 3.1. and 
4.0 signaling. Quality of Service and traffic shaping per port is 



provided via VCC PGR. SCR. and MBS parameters. Service 
classes are supported via Adaptation Layers 1,2, and 5 utilizing 
classes CBR, VBR-rt. VBR-nrt, UBR. and UBR+. 

Advanced Network Management 

Dexter provides extensive network management facilities via its 
internal SNMP agent and a supporting SNMP Network 
Management Application. A full range of functions is available to 
configure, monitor, and report upon network performance, 
configuration parameters, call management, fault management, 
and IP/Frame Relay network protocol statistics. 



Understanding Dexter Management 

Dexter management is available through Mariner Networks' 
SNMPNetwork Management Application Messenger*^, which 
provides local and remote access to one or more Dexter IAD's via 
SNMP. The application is designed to provide the network 
management capabilities expected from enterprise or carrier-class 
customers. Network management is generally defined to 
encompass two main areas, namely Monitoring and Control. 

• Network Monitoring is concerned with observing and analyzing the status and 
behavior of its network domain configuration and its devices. 

• Network Control is concerned with the altering of parameters of various 
configurations of the network devices and causing those components to perform 
predefined actions. 

In line with this concept. Dexter is a fully managed ATM IAD, 
which supports the following key disciplines: 

• Network Management 

• Traffic Management 

• Code Management 

• Security Management. 

Network Management 

You can manage Dexter's subsystems in any of the following 
ways: 

• From an ASCII terminal with a character-based command line interface that 
is directly connected to the RS-232 console monitor port on Dexter's front panel. 

• By remotely logging into the Dexter's Command Line Interface via a Telnet 
session. This session may be via the local Ethernet port. Frame Relay port, or in- 
band across the ATM WAN. 

• By accessing Dexter's SNMP Agent via an authorized networi< management 



station mnning Mariner Networks' SNMP Management Application "Messenger*. The 
network management station may reside anywhere in the network. 

Dexter's Messenger^ application can be run on any type of 
network management workstation irrespective of operating 
system or machine type. It can be run under HP OpenView*^ or 
independently, offering a complete network management 
environment for the enterprise or carrier class user. The graphical 
user interface (GUI) enables the operator to configure Dexter 
elements quickly and easily and to interrogate perfomnance data 
and traffic profiles in a variety of tables and charts. Multiple Dexter 
configurations and maps may be viewed simultaneously. 

Dexter can support simultaneous access by multiple network 
management stations to facilitate redundancy and continuous 
networi^ operational requirements. The SNMP agent comprises 
Dexter's enterprise MIB and a number of industry compliant 
networidng MIBs (ATM. FR. and MIB-II). 

Traffic Management 

Dexter's advanced traffic management functions include: 

• Priority queues per Quality of Sen/ice 

• Constant Bit Rate (CBR) 

• Real time Variable Bit Rate (VBR-rt) 

• Non-real time Variable Bit Rate (VBR-nrt) 

• Unspecified Bit Rate (UBR) 

• Unspecified Bit Rate Plus (UBR+) 

• Traffic shaping per port and per Virtual Circuit (TM 4.0). 

Dexter ensures that the Virtual Channel Connection (VCC) 
contract is respected at the Virtual Channel (VC) level. To reduce 
irregular bursts of traffic, a reshaping function is provided. 

Code Management 

Code management allows the networic administrator or network 
operator to manage the application and user configuration 
modules contained within Dexter. The application module contains 
the program logic necessary for Dexter to function. User 
configuration modules consist of parameters and network 
definitions that describe the network, voice characteristics, 
profiles, and packet/cell routing infonmation. 

Dexter's flash memory can hold multiple copies of application 
modules as well as multiple copies of user configurations, and 
allows an operator to switch between them. In this way, Dexter 
can be reloaded or re-configured to perfomn differently while still 
retaining the ability to recover from updates that fail to function as 



required. 

You can access Dexler's code management in any of the 
following ways: 

• Application and user configuration module data can be uploaded or 
downloaded using TFTP. Dexter contains a TFTP server that enables bi-directional 
processes, 

• Switching between application or user configuration data can be performed 
using either the console port via the command line interface (CLI). via a Telnet 
session, or remotely via the Management application. 

• Using the console monitor port, you can perform uploading and downloading 
of application or user configuration data. 

Providing multiple copies of application and user configuration 
data in flash memory enhances Dexler's network manageability in 
a customer premises environment. Dexler's advanced network 
management capabilities enable network control and monitoring 
to be performed quickly and simply with the minimum of end-user 
involvement. 

Security Management 

Dexter is configured with the following security features: 

Configuration Protection 

Access to Dexter via the console monitor port is password 
protected. This password can be changed at the customer's/end- 
user's discretion. A hardware-based reset feature is incorporated 
to enable recovery to a default password in the event of password 
loss. 

Network Access Protection 

Telnet access to Dexler's Command Line Interface (CLI) via the 
ATM, local Ethemet or Frame Relay network is provided and 
access is controlled via a password. 

Access to the Dexter SNMP agent is controlled via a domain 
name to prevent and limit unauthorized use. 



Typical Implementations 

Dexter simplifies ATM access at the customer premises. This is 
achieved through implementing Dexter as an ATM Interworicing 
Networic Temiinating Unit (NTU) that cleariy defines the boundary 
of the ATM network from the customer's local networi< 
communications equipment. Through its ATM intenA^orking 
capabilities. Dexter converges multiple services (voice, data, and 



video) over single or multiple upstream ATM links. The following 
diagram illustrates a typical configuration. 




Figure 2 Typical Dexter configuration 

Figure 2 illustrates a simple "mesh system" implemented between 
several office locations. All Dexters are configured to establish 
PVCs between remote locations and to the central location 
housing the host system and application servers. Multiple Dexters 
may be installed at the central location to provide sufTicient voice 
channel capacity for head office personnel. 
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Chapter 3 



Features and Components 



This chapter describes the main features and components of 
Dexter. 



Base Product 

The base Dexter 3000 product consists of a 3-sIot chassis 
enclosure \Arfth the following components: 

• Main processor board with application software loaded 

• Power supply assembly 

• 1 X RJ45 Ethernet port 

• . 1 X DB9 RS-232 console monitor port 

• Three blank single-slot filler plates. 

The following components are delivered with Dexter to facilitate 
power up and initial configuration: 

• Power supply cord 

• RS232 modem cable 

• Documentation CD-ROM package. 

System Component 

All Dexter units are based upon a main processor board design 
and chassis enclosure that facilitates the insertion of up to three 
Network or User Interface Modules. Available modules are 
described later in this chapter. 

The main processor board contains the CPU, various memory 
modules, operating system, and application code. Additionally, this 
board holds Mariner Networks' expedite^ processor, a 
proprietary technology that performs frame to cell conversion and 
data forwarding in hardware. This feature is described more fully in 
Chapter 4. 



Ethemet Port 



Dexter is equipped with a single RJ45 socket on the front panel 
system unit to facilitate either lOBaseT Ethemet or Telnet 



management access. In this way. Dexter can be configured 
without the need for any modules to be inserted prior to customer 
delivery. Initial configuration of IP addressing would need to be 
achieved via the console monitor port. 

Console Monitor Port 

Dexter is equipped with the DB9 RS-232 female DCE connector 
on the front panel system unit to facilitate initial configuration of the 
Dexter unit. 

Memory Configuration 

16MB of main memory is provided in all Dexter configurations. In 
addition to this memory offering. Dexter is configured with flash 
memory to hold multiple application and user configuration data, 
and boot PROM to support initial power-on and program load 
functions. 

Power Requirement 

Each unit is configured with an intemal auto-detecting 85-264 
VAC power supply with a fused power switch. A power cord 
applicable to the destination country is included. 

Documentation 

A printed Quick Start Installation Guide is delivered with all Dexter 
units. All other documentation relating to Dexter is available on an 
accompanying CD-ROM. Additionally, all user-related 
documentation is available by downloading from the Mariner 
Networks website. 

Cabling 

Each Dexter is shipped with an RS-232 DB9 DCE/DTE modem 
cable. Access to the console monitoring port is through a VT100 
temiinal device. 



Additional Required Components 

In addition to the base components supplied with the chassis. 
Dexter will need to be populated with one or more Network or 
User Interface Modules that connect the ATM WAN or the existing 
customer communications equipment. A brief description of each 
module is contained within this document. Further detailed 
information can be obtained by referencing the relevant Dexter 
3000 Supplementary Data Sheet, 



Optional Components 



The following optional components are available. 
Mounting Kits 

Dexter is designed to be either a standalone, wall-mounted, or 
rack-mounted unit. Mounting kits are available to facilitate the 
installation of the Dexter unit into a 1 9 inch communications rack 
or onto a wall. 

Cabling 

A number of cabling options is supported to accommodate 
connection of the ATM interface, and Frame Relay V.35/X.21 
attached router. Further cabling specifications are available upon 
request. 

Documentation 

All documentation relating to Dexter is available on a CD-ROM. 
This CD-ROM is shipped with Dexter or can be ordered 
separately. Please refer to the Mariner Networks website for 
further information on available publications. 



Modules 

This section describes the various network and user modules 
available for the Dexter IAD, The following list provides a summary 
functional description. 



Module Description Page 

T1/E1 Network module to connect to ATM or 

Frame Relay WAN, 3-5 

ATM T1 or E1 IMA Network module to connect to ATM WAN. 
Supports grouping of multiple ATM links into single VC. 3-6 

ATM DS-3/E3 Network module to connect to ATM WAN. 

3-7 



ATM OC-3 or STM-1 Network module to connect to ATM WAN. 

3-8 

SDSL Network module to connect to ATM or 

Frame Relay WAN over DSL. 3-9 

HDSL2 Network module to connect to DSL WAN. 

Configurable for ATM or Frame Relay. 3-10 

Synchronous Serial Network or User module to connect router 
or other Frame Relay device. 3-11 

1 0/1 OOBaseT User module used to connect local Ethernet 

hub or switch. 3-12 

Voice T1/E1/PRI User module to connect local PBX 

equipment 3-13 

Voice T1/E1/PRI + BRI User module to connect local PBX and 

ISDNBRI 3-15 

ISDN BRI User module to connect up to 3 S/T/U 

devices. 3-16 

Table 1 Module list description 



T1/E1 

There are two types of T1/E1 network module available for Dexten 

• IxportTI/EI 

• 4 X port T1/E1 announcement to be defined (TBD). 

Each module may be configured to operate in ATM cell 
delineation or Frame Relay HDLC delineation mode. Each 
interface is presented as an RJ48C female socket that can accept 
either a T1 (1 .5Mbps) or an El (2Mbps) facility interface. 

Each module has the following characteristics: 

• 1 or 4 ports each operating at either 1 .544Mbps or 2.048Mbps line rate. 

• Each port may connect to an ATM switch via UNI (3.0. 3.1 . or 4.0), or a 
Frame Relay DLCI compliant device. 

• Integrated CSU/DSU functionality. 

• Physical interface is electrical vioth impedance of 1 00/1 20 Ohms. 

• One or more modules may be inserted into any of Dexter's slots. 

• Both modules are easily swappable without the need for specialist knowledge 
or equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 



Figure 3 shows both module faceplates. 
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Figure 3 T1/E1 modules 



ATM T1/E1 IMA 

There is one type of the ATM Inverse Multiplexing over ATM (IMA) 
network module available for Dexter: 

• 4xport E1 orT1, 

This module may be configured to operate in a variety of logical 
IMA line groups. Each interface is presented as an RJ48C female 
socket that can accept either a T1 (1,5Mbps) or E1 (2Mbps) facility 
interface. 

The module has the following characteristics: 

• 4 ports, each operating at either 1 .544Mbps or 2.048Mbps line rate. 

• Each port may conned to an ATM switch via UNI using a supported 
interface, 

• T1 option has an integrated CSU/DSU functionality. 

• Physical interface is electrical with impedance of 1 00/120 Ohms. 

• One or more modules may be inserted into any of Dexter's slots. 

• This module is easily swappable without the need for specialist knowledge or 



equipment, 
type. 



Dexter will require rebooting and reconfiguring upon change of module 
Figure 4 shows the faceplate of the module. 
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Figure 4 ATM T1 or E1 IMA module 



ATM DS-3/E3 

There are two types of a ATM DS-3/E3 network module available 
for Dexter 

• 1 X port DS-3 announcement TBD 

• 1 X port E3 announcement TBD. 

Each module is configured to operate in ATM cell delineation 
mode. Each interface is presented as a BNC 75 Ohm female 
connector that can accept either a DS-3 (45Mbps) or an E3 
(34Mbps) facil'ity interface. 

Each modules has the following characteristics: 

• 1 port operating at 34Mbps or 45Mbps line rate. 

• Each port may connect to an ATM switch via UNI using a supported 
interface. 



• Physical interface is electrical with an impedance of 75 Ohms. 

• One or more modules may be inserted into any of Dexter's slots. 

• Both modules are easily swappable without the need for specialist knowledge 
or equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 

Figure 5 shows both module faceplates. 
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Figure 5 ATM DS-3/E3 modules 



ATM 0C.3/STM-1 

There are two types of ATM 0C-3/STM-1 network module 
available for Dexter: 

• 1 X port 00-3 announcement TBD 

• 1 X port STM-1 announcement TBD 

Each module is configured to operate in ATM cell delineation. The 
interface is presented as an optical fiber ST female connector that 
can accept either an OC-3 (155Mbps) or STM-1 (155Mbps) facility 
interface. 



The module has the following characteristics: 
• 1 port operating at 1 55Mbps line rate software configurable between either 



the OC-3 or STM-1 format. 

• Each port may connect to an ATM switch via UNI using a supported 
interface. 

• Physical interface is single or multimode optical fiber. 

• One or more modules may be inserted into any of Dexter's slots. 

• This module is easily swappable without the need for specialist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 

Figure 6 shows the module faceplate. 




Figure 6 ATM 0C-3/STM-1 module 



SDSL 

There is one type of the SDSL network module available for 
Dexter: 

• 2 X port SDSL announcement TBD 

The module may be configured to operate in ATM cell delineation 
or Frame Relay delineation mode. The module may be configured 
to communicate with another Dexter, DSLAM or other Central 
Office (CO) equipment. The module can be configured as either a 
CO or CPE device. 



The module has the following characteristics: 

• 2 ports operating in variable rate SDSL (Symmetric Digital Subscriber Line) 
using GlobeSpan's^ 2B1Q XDSL chip set. SDSL data rates of 144kb/s, 272kb/s. 
400kb/s. 528kb/s. 784kb/s. 1040kb/s. 1168kb/s. 1552kb/s, 2064kb/s. and 2320kb/s 
are supported using 2B1Q line encoding data rates. 

• Each port may connect to an ATM switch via UNI, or a Frame Relay 
compliant device. 

• Physical interface is electrical with impedance of 50/75 Ohms. The 
connectors are RJ1 1 terminating voice grade telephone wire local loops. 

• One or more modules may be inserted into any of Dexter's slots. 

• This module is easily swappable without the need for specialist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 

Figure 7 shows the module faceplate. 
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Figure 7 SDSL module 



HDSL2 



There is one type of HDSL2 network module available for Dexter: 
1 X port ATM/FR announcement TBD 

The module may be configured to operate in ATM cell delineation 



or Frame Relay delineation mode. The module may be configured 
to communicate with another Dexter, DSLAM. or other Central 
Office (CO) equipment. The module can be configured as either a 
CO or CPE device. 

The module has the following characteristics: 

• 1 port operating up to 1 .5Mbps using 2B1Q line encoding data rates. 

• The port may connect to an ATM switch via UNI, or a Frame Relay compliant 
device. 

• Physical interface is electrical with impedance of 50/75 Ohms. The connector 
is RJ1 1 terminating voice grade telephone wire local loops. 

• One or more modules may be inserted into any of Dexter's slots. 

• This module is easily swappable without the need for specialist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 

Figure 8 shows the module faceplate. 
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Figure 8 HDSL2 module 



SYNCHRONOUS SERIAL 

There is one type of the Synchronous Serial module available for 



Dexter: 

• 1 X port 

The module is configured to operate in Frame Relay mode, clear 
channel or channelized mode, or ATM mode via dear channel. 
The module can attach to an ewsting Frame Relay router or other 
Frame Relay compliant device. The interface can be configured 
for either V.35 or X.21 via an adapter cable.. 

The module has the following characteristics: 

• 1x DB25 female DCE/DTE synchronous port supporting. RS-530. or RS-449. 
Data rate can be set from 64K to 8.192Mbps, full duplex operation. 

• One or more modules may be inserted into any of Dexter's slots. 

• The module is easily swappable without the need for specialist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 

Figure 9 shows the module faceplate. 
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Figure 9 Synchronous Serial module 



10/100BaseT 



There is one type of the 10/100BaseT module available for 
Dexter 



4 X port 10/100BaseT announcement TBD 



The module is configured to attach to an existing Ethernet LAN via 
a hub or switch. Each RJ45 port is rate auto-sensing and provides 
erther switching of Ethemet packets between Dexter's LAN 
^ interfaces or routing/bridging via AAL5 encapsulation over the 
ATM WAN. 

The module has the following characteristics: 

• 4 ports of 1 0/1 OOBaseT for local Ethernet or Telnet management access. 

• Spanning Tree protocol is supported. 

• Each port is on its own segment. 

• One or more modules may be inserted into any of Dexter's slots. 

• The module is easily swappable without the need for specialist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 

Figure 10 shows the module faceplate. 
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Figure 10 10/1 OOBaseT module 



VOICE T1/E1/PRI 

There is one type of Voice T1/E1/PRI module available for Dexter: 



• 1xportT1/E1 

The module may be configured to operate in either T1 or E1 mode 
and connects to the customer's local PBX system. The module 
provides a T1/E1 trunk type interface that can support either 24 
(T1) or 30 (E1) channels of voice throughput. PBX supported 
interface signaling includes either Robbed Bit (T1), CAS {E1). or 
ISDN PRI using Common Channel Signaling (CCS) to provide 23 
(T1) and 30 (E1) bearer channels respectively for voice tmnking. 
The module also contains the necessary Digital Signal Processors 
(DSPs) and logic to provide voice compression, silence 
suppression, echo cancellation. AAL1AAL2 processing, and 
packet to cell conversions. 

The module has the following characteristics: 

• 1 port operating at either 1 .544Mbps (T1) or 2.048Mbps (E1), The module 
can be ordered \Artth support for 8, 16. 24, or 32 voice channels. These channels 
may be assigned to any time slot in the T1 or E1 . 

• Signaling supported includes RBS. CAS (E1) and ISDN PRI (CCS). 

• Supported CCS signaling for ISDN PRI includes PRI Net5 User. PRI Nets 
Network, and PRI QSIG. 

• AAL1 voice processing in accordance with af-vtoa-0078,000, 

• AAL2 voice processing in accordance with ITU-T 1.363.2. 

Voice processing includes G .71 1 (64K PCM). G,726 ADPCM, G.727 
EADPCM. G.729 CS-ACELP. G.729AB CS-ACELP. and G.723.1A. 

• Support for Fax Relay and voice-band signaling. 

• Physical interface is an RJ45 electrical with impedance of 1 00/1 20 Ohms. 

• One or more modules may be inserted into any of Dexter's slots. 

• The module is easily swappable without the need for spedalist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 
type. 



Figure 1 1 shows the module faceplate. 
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Figure 11 Voice T1/E1/PRI module 



VOICE T1/E1/PRI + BRI 

There is one type of Voice T1/E1/PRI + BRI module available for 
Dexter: 

• 1 xportT1/E1 + 1 xport ISDN BRI 

The PBX T1/E1 facility interface operates identically as outlined in 
the previous module. Additionally, this module incorporates an 
ISDN BRIport that provides for attachment to a videoconferencing 
codec (atthough it may be used with any ISDN BRI compliant 
device). 

The module has the following characteristics: 

• 1 port operating at either 1 .544Mbps (T1) or 2.048Mbps (E1). The module 
can be ordered with support for 8, 16, 24. or 32 voice channels. 

• Identical characteristics to that of the PBX E1/T1 module. 

1 ISDN BRI port providing 2 x 64K bearer channels and 1 x 16K D channel. 
Both S/T and U interfaces are supported. 

• One or more modules may be inserted into any of Dexter's slots. 

• The module is easily swappable wrthout the need for specialist knowledge or 
equipment. Dexter will require rebooting and reconfiguring upon change of module 



type. 



Figure 12 shows the module faceplate. 



Voice T1/E1/PRI + BRI 



Figure 12 Voice T1/E1/PRI + BRI module 



ISDN BRI 

There are two versions of ISDN BRI module available for Dexter 

• 2 X port ISDN BRI announcement TBD 

• 3 X port ISDN BRI announcement TBD 

This module is equipped with either a dual port or triple port ISDN 
BRI facility that supports S/T and U interfaces. Each port can be 
configured to support voice, fax, or voice-band data signals. Full 
voice processing is supported for compressed or uncompressed 
transmission across the ATM WAN. 

Each version of the module has the following characteristics: 

• 2 or 3 ports providing ISDN BRI service. Each port supports 2 x 64K bearer 
channels and 1 x 16K D channel. Both S/T and U interfaces are supported. 

• One or more modules may be inserted into any of Dexter's slots. 

• Both modules are easily swappable without the need for specialist knowledge 
or equipment. Dexter will require rebooting and reconfiguring upon change of module 



Figure 13 shows both module faceplates. 
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Figure 13 ISDN BRl modules 

Chapter 4 
Functional Description 



This chapter describes the functions of each main component in 
Dexter and provides an overview of various communication 
technologies. 



Architecture Overview 



Dexter comprises of a main processing board that contains core 
memory, application code, and optional interface modules. A key 
element of this design is Mariner Networks' proprietary processor 
technology, expedite^. 

The expedite^ processor consists of a cell switching fabric with 
segmentation and re-assembly processes and a cell forwarding 
architecture that includes a cell scheduler function. It contains the 
necessary logic and dynamic tables to translate between ATM 
VCs and Frame Relay DLCIs, Additionally, through its powerful 
scheduling ability, it supports current ATM and Frame Relay 
Quality of Service (QoS) attributes. The expedite^ processor 
uses Dexter's on-board CPU to build and maintain its tables and 
routing information. 

The expedite*^ processor's unique benefit is that once its tables 
have been defined, it converts, routes, and switches frames and 
cells effortlessly, in hardware, and releases the main CPU to 
perform other processor intensive tasks such as voice processing. 
Unlike other comparable CPE devices, this blend of technology 
enables Dexter to deliver the processing power and switching 
performance that would normally be found in larger and more 
expensive access units. 

Dexter's other key components are the following subsystems: 

• ATM Processing 

• Voice Processing 

• Network Management. 



ATM Processing 

This subsystem provides the broadband services to Dexter's 
applications. 

Overview 

ATM processing, frame to cell conversion and transmission of 
cells to the ATM network modules is performed by the expedite^ 
processor. 

The following ATM Adaptation Layers (AAL) and associated 
sen/ice classes are supported: 

Layer Service Class Mnemonic 



-7 • 



AAL1 



Constant Bit Rate 



CBR 



AAL2 



Variable Bit Rate 



VBR-rtVBR-nrt 



AAL5 



Unspecified Bit rate 



UBR UBR+ 



Table 2 Supported AAL protocols 



AAL1 Operation 



This layer is used to support all switched or permanent 
uncompressed voice calls. Uncompressed voice traffic is either 
carried as a stmctured or basic Nx64K CES cell stream as defined 
in the af-vtoa-0078.000 interoperability specification. Circuit 
Emulation Services (v2). 



This layer is used to support all switched compressed voice calls 
over the ATM network. All AAL2 voice traffic between a pair of 
Dexters is multiplexed across a single ATM VC. 



This layer is used to support all Frame Relay data frames and 
Intemet data packets over the ATM network. 



Dexter performs traffic shaping of its outgoing ATM cell flow in 
accordance with the relevant standard for Connection Traffic 
Descriptor that was negotiated with the ATM network. The 
relevant parameters used to specify unambiguously the 
conforming cells of the ATM connection are Peak Cell Rate 
(PCR). Sustainable Cell Rate (SCR), and Maximum Burst Size 
(MBS). Dexter contains two leaky buckets to support its QoS 
scheduling. 



Inverse Multiplexing over ATM Interface 



Dexter can be configured to accept up to 4 x 2Mbps circuits via a 
4-port E1/T1 IMA interface, which can be configured into two IMA 
logical groups. Typically, ATM PVCs would utilize all available 
circuits in the IMA group to provide greater throughput. An outline 
flow of ATM cells through an IMA configuration is illustrated in 
Figure 14. Here, an ATM data stream is split across three 
individual physical links on a cell-by-cell basis in a "round-robin" 
effect. 



AAL2 Operation 



AAL5 Operation 



Quality of Service 



IMA Virtual Unit 



Figure 14 IMA logic flow 

Frame Relay to ATM Operation 

Dexter supports both Frame Relay to ATM "Network" and 
"Service" interworking as defined by the Frame Relay Forum's 
Frame Relay/ATM Network and Service Interworking 
Implementation Agreements (FRF.5 and FRF.8 respectively). 

Network Interworking (FRF.5) 

This function is responsible for forwarding frames between the 
Frame Relay interface and the ATM Data Subsystem Dexter 
processes frames received from the Frame Relay interface as 
follows: 

1 . De-multiplexed according to their DLCI. 

2. Stripped of their HDLC encapsulation headers. 

3. BECN. FECN. and DE congestion and flow control 
indicators are mapped according to ATM EFCI and CLP 
settings. 

4. Re-encapsulated In ATM AAL5 CPCS PDUs. 

5. Segmented and multiplexed over the UTOPIA cell 
interface according to the ATM VCC. 

In the reverse direction, the ATM cell traffic is processed as 
follows: 

1 . ATM AAL5 CPCS PDUs reassembled from the UTOPIA 
cell interface. 



2. De-multiplexed acxording to the ATM VCC. 



3. Stripped of their AAL5 encapsulation overhead bytes. 

4. ATM EFCI. DE congestion, and flow control indicators are 
mapped according to FR BECN. FECN» and DE settings. 

5. Multiplexed over the appropriate Frame Relay interface 
according to DLCI. 

Figure 15 illustrates Network intenA^orking mapping performed 
between frames and cells. 
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Figure 15 Network interworking mapping 



Service Interworking (FRF.8) 



This function is essentially the same as the previous function, 
except that protocol conversion algorithms are applied to convert 
Frame Relay bridged or routed PDU to ATM bridged or routed 
PDUs. Frames received from the Frame Relay interface are 
processed as follows: 

1 . De-muttiplexed according to their DLCI. 

2. Stripped of their HDLC encapsulation headers. 

3. Network protocol encapsulation headers mapped from 
those specified in RFC 1490 (for Frame Relay) to those 



specified in RFC 1483 (for ATM). 

4. Re-encapsulated in ATM AAL5 CPCS PDUs. 

5. Segmented and multiplexed over the UTOPIA cell 
interface according to the ATM VCC. 

In the reverse direction. Dexter processes the ATM cell traffic as 
follows: 

1 . ATM AAL5 CPCS PDUs reassembled from the UTOPIA 
cell interface. 

2. De-multiplexed according to the ATM VCC. 

3. Stripped of their AAL5 encapsulation overhead bytes. 

4. Network protocol encapsulation headers mapped from 
those specified in RFC 1483 (for ATM) to those specified in 
RFC 1490 (for Frame Relay). 

5. Multiplexed over the appropriate Frame Relay interface 
according to DLCI. 

Figure 16 illustrates Service Interworking mapping perfomied 
between frames and cells. 




Figure 16 Service interworking mapping 

Ethernet Operation 

Dexter is assigned an IP address and subnet mask to each 
network port (including ATM WAN ports). Services such as 
Domain Host Control Protocol (DHCP) and Network Address 
Translation (NAT) are supported. 

Dexter perfomis both local IP routing (RIPvl & v2) and switching 
between its local and network ports. Bridging between a pair of 



Dexters is achieved by using ATM bridging muHi-protocol 
encapsulation techniques over AAL5 (RFC 1483) and Classical IP 
encapsulation (RFC1577). 

Other protocols built into the Dexter IP stack include UDP, TCP, 
TFTP, SNMP, ARP. and ICMP. Telnet packets received from the 
local ports or via the network ports are converted to command 
strings and passed to the Dexter's command line interface (CLI) 
for parsing. 

Domain Host Configuration Protocol 

The Dynamic Host Configuration Protocol's (DHCP) purpose is to 
enable individual computers on an IP network to extract their 
configurations from a server (the 'DHCP server") or servers, and in 
particular, servers that have no exact information about the 
individual computers until they request the information. The overall 
purpose of this is to reduce the work necessary to administer a 
large IP network. Dexter contains a DHCP server function 

Network Address Translation 

Network Address Translation (NAT) is used to translate one IP 
address to another. NAT can be used to allow multiple PCs to 
share a single Internet connection. It can also be used as a 
security tool by shielding the IP addresses of devices within the 
attached intranet. NAT can also be used for general IP address 
management by protecting the attached intranet from excessive 
address changes due to other network addressing constraints. 



Voice Processing 

This subsystem provides the voice and video-oriented 
narrowband services to Dexter's applications. 

Overview 

This section describes the functional aspects of Dexter's voice 
processing capabilities. Dexter's voice traffic across the ATM 
WAN is managed using a mixture of both AAL1 CBR connections 
and AAL2 VBR-rt connections. 

AAL1 is used to carry uncompressed voice channels and 
associated Robbed Bit or CAS signaling transparently, end-to- 
end. AAL2 is used in conjunction with Mariner Networks' 
proprietary signaling and compression engine to switch and carry 
packetized, compressed voice traffic end-to-end. The AAL type is 
software configurable on a trunk channel basis, and compression 
algorithm/ratio basis. 



Circuit Emulation Services 



Dexter utilizes structured Circuit Emulation Services (CES), nailed 
up circuits supporting Nx64K (uncompressed) between Dexters, 
or between Dexter and other vendors' equipment supporting 
standards-based CES. While uncompressed CES-based 
connections are less efficient than compressed. AAL2 based 
connections, they offer the greatest benefit in terms of end-to-end 
voice quality and interoperability. 

Figure 17 illustrates some of the network interconnection 
scenarios that can be implemented using structured circuit 
emulation with a Dexter network. 




Figure 17 Dexter CES-based voice connections 



In Figure 17, each of the ATM PVCs shown (A. B. C) carries a 
fixed, constant bit rate stream of ATM cells. The cell payloads. 
formatted according to the rules specified in af-vtoa-0078.000, 
contain voice samples and robbed bit signaling information for the 
trunk channels that the associated PVCs are configured to 
transport between the attached voice interfaces and the ATM 
network. 

A CES connection provides a "nailed-up" transport for TDM voice 
data and voice signaling, allowing geographically dispersed 
telephony endpoints to communicate transparently over the ATM 



network. 



Circuits can be configured for eitlier "Basic Mode", meaning that 
trunk channels are transported without associated signaling, or 
CAS mode, meaning that CAS/robbed bit signaling infonmation is 
included in the cell payloads. The latter is useful for connecting 
non-PBXtype equipment (e.g.. analog handsets) at one end to 
PBX/tmnk temninating equipment at the other end (loop 
extension). 

Compressed Voice Services 

By using AAL2 VBR-rt ATM circuits in conjunction with Dexter's 
compression and signaling software. Dexter can more efficiently 
transport voice and fax traffic across the ATM WAN. 

AAL2 provides for the bandwidth-efficient transmission of low-rate, 
short, and variable packets in delay sensitive applications. ATM's 
VBR-rt services enable statistical multiplexing for the higher layer 
requirements demanded by voice applications, such as 
compression, silence detection/suppression, and idle channel 
removal. Additionally, in contrast to AAL1 (which has a fixed 
payload). AAL2 offers a variable payload within cells and across 
cells. 

Mariner Networks' compression and signaling software terminates 
the local signaling channels and provides inter-Dexter proxy 
signaling over AAL5. This signaling provides for compressed calls 
that includes Robbed Bit/CAS modes, and out-of-band Common 
Channel Signaling (CCS) for a number of message oriented 
signaling protocols. 

Initial releases of Dexter support compressed calls with in-band 
signaling (Robbed Bit/CAS) for non-ISDN T1/E1 interfaces and 
the following CCS variants when Dexter is configured for ISDN 
PRI mode: 

• PRI Nets User Mode 

• PRI Nets Network Mode 

• PRI QSIG. 

Figure 1 8 illustrates some of the networic interconnection 
scenarios that can be implemented using a network of Dexters 
and voice compression and multiplexing technologies. 




Figure 18 Dexter CES and AAL2-basecl voice 
cx)nnections 

Figure 18 has the following key attributes: 

1 . Any combination of AAL1 uncompressed and AAL2 
compressed calls can be configured and carried by Dexter. 

2. In addition to an AAL2 VCC between a pair of Dexters, an 
AAL5 signaling VCC is required to canry Dexter's proprietary 
signaling protocol for switched, compressed voice/fax calls. 

3. Inter-Dexter AAL2 compressed VCCs can be used to connect 
dissimilar PBX technologies (e.g., ISDN PRI using CCS to 
standard Tl using robbed bit signaling). 

4. Dexter can also support analog interfaces that directly 
interface to fax machines, emulating the functions of a PBX to 
the attached devices. 

Protocols and Standards Compliance 

Dexter implements a combination of both standards-based and 
non-standards-based software protocols. The following sections 
provide an overview of these protocols. 

AAL1 

Dexter implements Nx64K structured mode CES over AAL1 , as 
defined in af-vtoa-0078.000. Dexter is software configurable, on a 



per-VCC basis, to mn either Basic or CAS-mode CES for 
configured trunk channels. Trunk channels carried via CES are 
transported in uncompressed. 64K PCM fomnat. Dexter does not 
implement unstnjctured mode CES (as defined in af-vtoa- 
0078.000), nor does it implement SRTS clock recovery as defined 
for AAL1 transport by the ATM Forum and ITU. 

AAL2 

Dexter implements a software based AAL2 implementation that is 
proprietary. This implementation utilizes the "general framework 
and Common Part Sublayer (CPS)" of the AAL type 2 defined in 
ITU-T Recommendation 1.363.2. The associated cell payloads 
comprise compressed voice/fax data output by the Dexter 
compression engine. 

It is Mariner Networks policy to implement standards-based 
software solutions wherever possible to maximize interoperability 
opportunities. Once the standards forAAL2 signaling have been 
agreed and accepted, Mariner Networi<s will implement such 
solutions into Dexter's AAL2 voice processing software. 

AAL5 

Dexter implements the ITU-T 1.363.5-compliant AAL5 UBR 
transport mechanisms widely deployed today. This service is used 
to convey Dexter voice signaling messages in conjunction with 
AAL2-based voice traffic. 

Voice Compression 

Voice compression is perfomned by Dexter's compression engine 
that consists of software logic and a number of Digital Signaling 
Processors (DSPs). Dexter can be configured to operate with a 
maximum of 4 DSPs. Each DSP can support the processing of 8 
voice channels concurrently. Dexter can be configured to support 
any set of the following voice encoding techniques: 

G.711 PCM. 64Kbps 

• G.726 ADPCM, rates 16, 24, 32, and 40Kbps 

• G.727 EADPCM. rates 16, 24, 32, and 40Kbps 

• G.729A CS-ACELP and G.729B CS-ACELP. 8kbps rate 

• G.723.1 A, rates 5.3 and 6.3Kbps. 

Proprietary Protocols 

As the ATM Forum and/or the ITU do not yet standardize signaling 
for AAL2, Mariner Networks utilizes Dexter's proprietary signaling 
protocol to establish and tear down individual compressed voice 
calls. These calls are signaled using Robbed Bit/CAS/CCS modes 



on the facility side, and converted to/from Dexter's proprietary 
"Q,931-like" signaling protocol for managing inter-Dexter call 
states. 

PBX Interface Mode 

Dexter can operate in one of three modes: North American T1 , 
Standard E1, and E1-based ETSI ISDN PRL 

In T1 mode, narrowband signaling is via the AB bit transitions in 
robbed bit frames of the T1 Super Frame (SF) or Extended Super 
Frame (ESF) muttiframe. In E1 (non PRI) mode, nan^owband 
signaling is via CAS AB bit transitions in slot 16 of all frames in the 
E1 (FAS/CAS or FAS/CAS-CRC4) multiframe. In E1 PRI mode, 
nan-owband signaling is configurable as QSIG, PRI NETS User 
Side, or PRI NETS Switch Side, via CCS in timeslot 16 of all 
frames in the El (FAS/CAS or FAS/CAS-CRC4) multiframe. 

Trunk Channel Signaling 

Dexter supports the following narrowband signaling protocols for 
trunk channel signaling. For each channel, one of the following 
may be selected as the signaling protocol: 

• Foreign Exchange Station Loop Start or Ground Start 

• Foreign Exchange Office Loop Start or Ground Start 

• E&M Immediate Start 

E&M Delay Start 

E&M Wink Start, 

This operation is unavailable when Dexter is operating in PRI 
mode. 

Voice Coding Profiles 

PCM voice samples from the PBX interface are swrtched through 
Dexter's on-board Digital Signaling Processors (DSPs), on a per- 
call basis, in order to perform the required compression, silence 
suppression, voice activity detection, and echo cancellation 
processes. All DSPs (up to a maximum of 4) are loaded v\nth the 
same image at power up, which supports the following protocols 
(on a per channel basis, 8 channels per DSP): 

G.711 

G.729A and B 

• G.726 
G.727 

• Standard Fax relay. 



Configuration of the DSP feature set is achieved through the 
creation of "Voice Coding Profiles". A coding profile is a set of 
configuration parameters that is assigned to a compressed call. 
The infomnation in the coding profile infonms the DSP how to 
process and route the compressed call through the system. 

Coding profiles with common characteristics must be configured 
on both Dexter peers in order for a call to be successfully placed 
between them. At the originating end, a coding profile is assigned 
to a destination telephone number. When a call request for a 
particular destination is received from the telephony interface at 
the originating end. the parameters from the associated coding 
profile are negotiated with the remote peer via Dexter's proprietary 
signaling message elements. At the remote end. a coding profile 
will have been associated with the telephony destination through 
prior configuration. 

Common elements from the originating side's coding profile and 
the destination side's coding profile are then negotiated and 
converged upon (via signaling) to create the set of parameters 
used to configure the associated DSP voice channels at both 
ends. Once this process is completed, the voice call is considered 
active. 

Dial Plan Configuration 

in addition to physical resource configuration (PBX mode, FXO, 
FXS, etc.). a dial plan that specifies how to route calls between 
Dexter peers is required. Dexter maintains its own dial plan that 
contains the following information: 

• Dialled digit timeouts and termination sequences 

• Narrowband hunt group definitions 

• Broadband hunt group definitions 

• Fonwarding criteria. 

SNMP 

Standard MIB support for Dexter includes: 

• RFC 1406 Standard T1/E1 MIB 

• Supplemental MIB supporting ANSI T1 .231 . 

Additionally, Dexter is configured with its Enterprise MIB structure 
to facilitate the reporting of non-standard object elements such as 
ISDN PRI infomnation. 



Network Management Processing 



This subsystem provides the facility to control and configure 
Dexler's different subsystems. 

Overview 

Briefly, the Networi^ Management Subsystem comprises four main 
components that enable a network operator to configure, control, 
report, and perfonn diagnostics upon Dexter. These elements are: 

- • Configuration Management 

• Connection Management 

• Fault Management 

• Performance Management. 

Configuration Management 

This component provides functions to configure all aspects of 
Dexler's physical interfaces, signaling protocol parameters, and 
call control parameters. From a management perspective, this 
involves the following entities: 

• General node configuration 

• E1/T1 port and subchannels 

• BRI-ISDN, lOBaseT, V.35 . and RS-232C ports 

• ATM and IMA ports 

• Nan-owband signalling 

• Inter-Dexter communications 

• Voice coding profiles 

• Routing, nanrowband, and broadband addressing tables 

• QAM segmentation end points table 

• Frame Relay and IP interworidng tables 

• CES configuration. 

Connection Management 

Connection Management is a set of functions that is used to track 
the various call or connection oriented entrties and configuration of 
PVCs. including applications they support. From a node 
management perspective, this involves describing the details of: 

• Active call connections between narrowband and broadband resources 

• Active broadband connections for the total system 

• PVCs created for the broadband entities 



PVCs created for the narrowband entities 



Call history information. 



Fault Management 



Fault Management is a set of functions that enable the detection, 
isolation, and con-ection of abnormal operation of the 
telecommunications parts of the network and its environment. 
From a node perspective, this tracks the following entities: 



Sundry fault management and vendor-spedfic diagnostics. 



Performance Management provides functions to evaluate and 
report upon the behavior of telecommunication/data equipment 
and the effectiveness of the overall network or network element. 
From a node management perspective, this involves general 
perfomnance, traffic, and data collection routines against the 
following entities: 



Physical facility and port failures 

Call control failures 

ATM 0AM cell loopback tests 



Performance Management 



Physical layer perfomnance monrtoring of all ports 

Cell level performance monitoring 

ATM layer protocol and performance monitoring. 
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standards Compliance 



This section lists the standards and compliance specifications 
relevant to Dexter. 

ANSI Documents 

(1 ) T1 .CBR-1 99X Draft - Broadband ISDN - ATM Adaptation Layer for Constant Brt 
Rate Services, Functionality and Specification, November 1992. 

(2) T1. 102-1 993, Digital Hierarchy. Electrical Interfaces, December 1993. 

(3) T1 .107-1995. Digital Hierarchy, Fomiats Specifications, 1995. 

(4) T1 .231-1993. Digital Hierarchy, Layer 1 In-Service Digital Transmission 
Performance Monitoring, September 1993. 

(5) T1 .403-1 995. Carrier-to-Customer Installation, DS1 Metallic Interface, March 
1995. 

(6) T1 .408-1 990. Integrated Services Digital Network (ISDN) Primary Rate - 
Customer Installation Metallic Interfaces Layer 1 Specification, September 1990. 

(7) T1 .606, T1 .606a. T1 .606b Frame Relay Bearer Service, Architectural Framework 
and Service Description, ANSI, 1990. 

(8) T1 .646-1 995. Broadband ISDN, Physical Layer Specifications for User-Network 
Interfaces Including DS1/ATM, 1995. 

(9) EIAn"1 A-547. Networic Channel Tenninal Equipment for DS1 Service. March 
1989. 

ATM/Frame Relay Forum Documents 

(1 0) AF-VTOA-0078.000. Circurt Emulation Sen/ice Interoperability Specification. 
Version 2.0. January 1997. 

(1 1 ) The ATM Forum, af-vtoa-0089.000, "Voice and Telephony Over ATM - ATM 
Trunking using AAL1 for Narrowband Services Version 1.0'. July 1997. 

(12) The ATM Forum, af-phy-0086.000, "Inverse Multiplexing for ATM (IMA) 
Specification, Version 1.0. July 1997. 

(1 3) The ATM Forum, af-vtoa-01 1 3.000. "ATM Trunking using AAL2 for Narrowband 
Services'. Version 1 .0, February 1 999. 

(14) UTOPIA, An ATM-PHY Interface Specification. Level 2. Version 0.95. June 1 995. 

(1 5) ATM User-Networic-lnterface Specification. Version 3.1 . September 1 994, ATM 
Forum. 

(1 6) UTOPIA. An ATM-PHY Interface Specification, Level 2, Version 0.95, June 1 995. 
ATM Forum. 

(17) Networic Working Group. RFC 1483. "Multiprotocol Encapsulation over ATM 
Adaptation Layer 5". 



(1 8) FRF.1 .1 , User-to-Network Implementation Agreement. 

(1 9) FRF.3.1 , Frame Relay Forum Multiprotocol Over Frame Relay, 

(20) Frame Relay/ATM PVC Network IntenArorking Implementation Agreement. 
Document Number FRF.5, December 20, 1 994. 

(21) Frame Relay Forum. Frame Relay/ATM PVC Service Inteworking 
Implementation Agreement, Document Number FRF.8, April 15,1 995. 

IETF 

(22) RFC 1483 Multiprotocol Encapsulation Over AAL5, July 1993. 

(23) RFC 1490 Multiprotocol Interconnect Over Frame Relay, July 1 993. 

(24) RFC 1 577 Classical IP and ARP over ATM, January 1 994. 

ITU Documents 

(25) ITU-T Recommendation G. 1 68, Digital Network Echo Cancellers, April 1 997. 

(26) Draft new ITU-T Recommendation 1.363.2. B-ISDN ATM Adaptation Layer Type 2 
Specification. February 1997. 

(27) ITU-T Recommendation 1.362 B-ISDN ATM Adaptation Layer(AAL) Functional 
Description. 

(28) ITU-T Recommendation 1.363 B-ISDN ATM Adaptation Layer(AAL) Description. 

(29) Recommendation G.703, Physical/Electrical Characteristics of Hierarchical Digital 
Interfaces, 1 991 . 

(30) Recommendation G.704, Synchronous Frame Structures Used at Primary and 
Secondary Hierarchical Levels, 1991. 

(31) Recommendation G.706, Frame Alignment and Cyclic Redundancy Check (CRC) 
Procedures Relating to Basic Frame Structures Defined in Recommendation 
G.704, 1991. 

(32) Recommendation G.804, ATM Cell Mapping into Plesiochronous Digital Hierarchy 
(PDH), January 1993. 

(33) Recommendation G.823, The Control of Jitter and Wander Within Digital 
Networks Which are Based on the 2048 kbit/s Hierarchy, 1993. 

(34) Recommendation G.826, Error Perfomiance Parameters and Objectives for 
International, Constant Bit Rate Digital Paths at or above the Primary Rate, 1993. 

(35) Recommendation G.832, Transport of SDH Elements on PDH Networks: Frame 
and Multiplexing Structures, 1993. 

(36) Recommendation 1.233.1 , Framework for providing additional packet mode 
bearer sen/ices, ITU-T. 1988. 

(37) Recommendation 1.370, Congestion management for the ISDN Frame Relaying 
bearer service, ITU-T, 1988. 

(38) Recommendation 1.431 , Integrated Services Digital Network (ISDN) User-Network 
Interface, Primary Rate UNI Layer 1 Specification, March 1993. 

(39) Recommendation 1.432, Broadband Integrated Services Digital Network (B-ISDN) 
User-Network Interface, Physical Layer Specification, March 1993. 

(40) Recommendation 1.610, Broadband Integrated Services Digital Network (B-ISDN) 
Operation and Maintenance, Principles and Functions, March 1993. 

(41 ) Recommendation Q.922 ISDN Data Link Layer Specification for Frame Mode 



Bearer Services. 1992. 

(42) ITU-T Recommendation Q.931. DSS1 - ISDN User-Network interface layer 3 
specifications for basic call control. 

(43) Recommendation Q.933, Digital Subscriber Signaling System No (DSS 1) 
Signaling For Frame IVIode Basic Call Control, ITU-T. 1 993. 

Other Related Documents 

(44) EN50082-1 "Electromagnetic compatibility. Generic immunity standard. Part 1 : 
Residential, commercial and light industry". EN 50082-1 : 1997 (or BS EN 50082- 
1 !1 998). 

(45) ENV 50204 "Radiated electromagnetic field from digital radio telephones - 
Immunity tesT. ENV 50204:1995. 

(46) lEC 61 000-4-2 "Electromagnetic compatibility (EMC). Part 4-2: Testing and 
measurement techniques. Electrostatic discharge immunity tesT. lEC 61000-4-2 
Consol. Ed. 1.1 (ind. ami). 1999-05. 

(47) lEC 61 000-4-3 "Electromagnetic compatibility (EMC). Part 4-3: Testing and 
measurement techniques, Radiated, radio-frequency, electromagnetic field 
immunity tesf. lEC 61000-4-3 - Consol. Ed. 1.1 (incl. ami), 1998-11. 

(48) lEC 61 000-4-4 "Electromagnetic compatibility (EMC), Part 4: Testing and 
measurement techniques. Section 4: Electrical fast transient/burst immunity test 
Basic EMC Publication". lEC 61000-4-4 - Ed. 1.0. 1995-01. 

(49) lEC 61 000-4-5 "Electromagnetic compatibility (EMC). Part 4: Testing and 
measurement techniques. Section 5: Surge immunity tesf. lEC 61000-4-5 - Ed 
1.0. 1995-02. 

(50) lEC 61 000-4-6 "Electromagnetic compatibility (EMC). Part 4: Testing and 
measurement techniques. Section 6: Immunity to conducted disturbances, 
induced by radio-frequency fields'. lEC 61 000-4-6 - Ed. 1 .0, 1 996-04. 

(51) lEC 61000-4-8 'Electromagnetic compatibility (EMC). Part 4: Testing and 
measurement techniques. Section 8: Power frequency magnetic field immunity 
test. Basic EMC Publication". lEC 61000-4-8 - Ed. 1.0, 1993-06. 

(52) lEC 61 000-4-1 1 "Electromagnetic compatibility (EMC). Part 4: Testing and 
measuring techniques, Section 11: Voltage dips, short interruptions and voltage 
variations immunity tests". lEC 61000-4-11 - Ed. 1.0, 1994-06. 

(53) EN50081-1 "Electromagnetic compatibility, Generic emission standard. Part 1: 
Residential, commercial and light industry". EN 50081-1:1992. 

(54) FCC Part 1 5 "RADIO FREQUENCY DEVICES". Downloaded October 1 998. 
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1.1. Scope 



Mako is a Mariner Networks proprietary technology that performs frame to cell conversion and data 
forwarding in hardware. It consists of a cell switching fabric with Segmentation and Reassembly at the edge. 
It contains the necessary logic and tables to translate between ATM VC's and Frame Relay DLCTs. It also 
contains scheduling ability to support ATM and Frame Relay Quality of Service (QoS). 

This document describes the fimction and architecture of an implementation of Mako technology for the 
Dexter 30xx-series of switches that will increase throughput to wire speed. The objective is to convert and 
forward up to a maximum of 1024 data streams entering through an array of 8 Frame Relay ports, at up to 
2.048 Mbps per port, to correlated ATM connections passing through a single UTOPIA level 2 interfece 
while concurrently converting and forwarding up to a maximxim of 1024 incoming ATM connections to an 
array of 8 Frame Relay ports, at up to 2.048 Mbps per port. 

In summary, this Mako implementation is expected to convert and forward up to 1024 fiiU duplex 
connections between Frame Relay and ATM at an aggregated throughput of up to 32 Mbps. 

1.2. Document Overview 

This document is intended to be a self-contained description of the requirements for the Mako. It is intended 
to serve as the controlling technical document for the en^neering development effort. 

1.3. References 

(1) ATM User-Network-Interface Specification, Version 3.1, September 1994, ATMForum. 

(2) UTOPIA, An ATM-PHY Interfece Specification, Level 2, Version 0.95, June 1995, ATM Forum, 

(3) Frame Relay/ATM PVC Network Interworking Implementation Agreement, Document Number 
FRF.5, Dec 20, 1994, Frame Relay Forum.Frarae Relay/ATM PVC Service Interworking 
Implementation Agreement, Document Number FRF.8, Apr 15, 1995, Frame Relay Forum. 

(4) Voice over Frame Relay Implementation Agreement, Document Number FRF. 1 1 , Dec 1 998, Frame 
Relay Forum. 

(5) Frame Relay Fragmentation Implementation Agreement, Document Number FRF, 12, Frame Relay 
Forum. 

2. Features 

Mako will support the following: 

• Utopia level 2 interface for ATM cell ingress and egress. 
Processor interface for both configuration/control and data. 
1024 virtual connections. 

• AAL-5 segmentation and reassembly. 
32 Mbps throughput. 

• ATM QoS support per VC: CBR, VBRrt. VBRnrt, UBR 

• Per port pacing. 
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Frame Relay QoS support per DLCI: CIR. 



4. Functional Description 

Figure 4.1 Mako Block Diagram 

Inside the Makodata is held as ATM cells in a common buffer memory. Each cell is placed in a buffer upon 
ingress and remains in that same buffer imtil egress. Inside Mako, cells are virtually forwarded by physicaUy 
passing only the buffer number (BN). 

Frames enter the TDM Ports inter&ce directly from a TDM highway. The Tdm Res block translates the 
incoming port and DLCI numbers to an internal Ci (Connection Index), via a binary search table lookup in 
the TRT (TDM Resolution Table). 

The Seg block converts the frame to an AAL-5 cell stream and presents the AAL-5 cells to the 
PointerSwitch for forwarding. Depending on information in the XT (Switch Table), cells are forwarded 
either back out to TDM port, to the CPU, to an ATM Cell Port or to the HoldQueue. 
Cells belongmg to outgoing Frames enter the Tdm Reas block from the PointerSwitch. Based on per Ci 
information in the TXT (Tdm Translation Table), Tdm Xlt adds appropriate headers and trailers and inserts 
the correct DLCI and port nxmibers. Tdm Xlt then passes the Frames out through the Tdm I/F. 

Incoming ATM cells streams enter through the Utopia port where they are presented to the CellRes block. 
CellRes translates tiie VPI, VCI and PTI fields to a Ci, via a binary search table lookup in the URT (Utopia 
Resolution Table). 

CellRes presents incoming cells to the PointerSwitch. The PointerSwitch virtually switches cells to their next 
destination. Depending on information in the XT (Switch Table), cells are forwarded either back out to an 
ATM cell port, to the CPU, to a TDM Port or to the HoldQueue. 

Outgoing ATM Cells enter the CellXlt block from the PointerSwitch. CellXlt uses per-Ci information in die 
UXr (Utopia Translation Table) to assign the appropriate VPI and VCI to outgoing cells. 

CellXlt then passes the Cells out through the Cell I/F. 

When a cell stream requires buffering and retransmission with controlled QoS, its cells are switched to the 
CellSched block, CellSched holds queued cells imtil QoS information in the ST (Schedule Table) indicates 
they should be forwarded back out to the outside world. A proprietary register array, the BT (Bubble Table) 
is used to determine cell order. 

The CellSched block is a multi-service cell scheduler. It receives per-Ci QoS requirements from the ST 
(Scheduler Table). Based on information in the ST and conditional on Cell availability information from the 
HoldQueue block, it sequences cell forwarding requests per-Ci compliant with CBR, VBRrt, VBRnrt and 
UBR standards. 

5. Theory of Operation 

Mako is a cell based core switch with cell to frame and cell to packet conversion at the edge. The Mako 



112 



implementation supports Frame but not Packet ports so it only has cell to firame conversion and no cell to 
packet conversion. 

5.1. Cell Buffering and Queuing 

Data from any port either arrives as cells or is converted to cells. Each cell is assigned a unique BuflFer 
Number (BN) in the range of 1 to MaxBN-1. In Mako, MaxBN is expected to be about 1800. The exact 
value won't be determined until late in the design phase. Each BN corresponds to 52 byte cell buffer (BPld) 
and a block of pointers (BPtr). Incoming cell data is stored in the BPld associated with its BN. Vahies are 
adjusted in the cell's BPtr which position the cell's BN in a threaded queue for processing. There are also a 
BPtr and BPld associated with BN = 0. BN = 0 is a special case associated with ATM Idle Cells. 

BNs are always ordered in threaded queues. A queue of BPtr's is used to link BNs within queues. Each BPtr 
contains the following fields: 

BPtrNxt contains the next BN in the threaded queue. 

BptrClSel contains a one bit selector bit for PointerSwitch clients with dual client ED's. 

The BptrClSel field is not related to queueing but is packaged within BPtr for convenience. It's function will 
be explained later. 

5.2. Connection Queuing 

Mako tracks connections by unique Connection Indexes (Ci's) in the range of 0 to MaxCi - 1. In Mako, 
MaxCi is 1024. There are a number of lists that are indexed by Ci which are used to control processing and 
forwarding of cells on a per-connection basis. 

After initialization, there are no cells in the system. All BNs are ordered in the Free Queue (FreeQ). There is 
a list of empty pointers (CiPtr*s), indexed by Connection Index (Ci). As cells enter Mako and are processed 
and forwarded, these pointers will become BN queue pointers. BN^s will be moved firom FreeQ to the CiPtr's 
and back to FreeQ. Each CiPtr contains the following elements: 

Ciln contains the BN of the most recent cell fi'om an input port. 
CiSch contains the BN of the next cell to be processed by the CellSched block. 
CiPktFrm contams the BN of the next cell to be processed by FrmXlt. 
CiOut contains the BN of the next cell to be sent out to an output port. 

Ciln is also the be^nning of the queue and CiOut is the end. 

A general implementation of Mako would include another element in CiPtr, named CiL3, which would 
contain the BN of the next cell to be processed by the Layer3 block. However, the Layer-3 processing block 
is presently not included and neither is its corresponding pointer element. 

5.3. Cell Input 

ATM cells ingressing through the Cell Interfece are examined by the CellRes block. The VPI, VCI and 
PTImsb (most significant bit of the PTI field) are compared against entries in the Utopia Resolution Table 
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(URT) for a match. Each entry in the URT contains the following fields: 



UrT(Us)->Key (bits 0 - 3 1 of 1st word) 
UrT(Us>>Ci (bits 0 - 12 of 2nd word) 
UrT(Us>>unused (bits 13-31 of 2nd word) 

UrT(Us)->Key contains the following sub fields: 

Key->PtiMsb (bit 0) = ATM hdr TPI field msb 

Key->Vci (bits 1 - 16) = ATM hdr VCI field 

Key-> Vpi (bits 1 7 - 24) = ATM hdr VPI field 

Key->Phy (bits 25 - 29) = Utopia PHY number 

Key->Ut (bits 30-31) = Utopia number 
Entries in UrT are ordered by the value in Key. 

The URT is ordered by bhe key field and searched by a binary search algorithm. If a match is found for the 
key of the incoming cell, the Ci is read and the cell is passed on to the Pointers witch. If no match is found, 
the UnkCell counter is incremented and the cell is discarded. 

5A. CeU Output 

The CellXlt block receives Ci's fi-om the PointerSwitch block. On receipt of a Ci, CellXlt adds the Ci into the 
CellOut FIFO. Each element in the CellOut FIFO contains one field: 
CxCi contains the Ci to which the cell applies. 

If the CellOut FIFO is not empty, CellXlt removes the first entry. CellXlt indexes the CiPtr table by the Ci 
removed firom the CellOut FIFO and retrieves the BN fi-pm CiPtr->CiOut. It then indexes the BPld table by 
this BN to find the header and payload of the cell to be output. CellXlt then uses the Ci fi'om the CellOut 
FIFO to index the Utopia Translation Table (UXT), Each entry in the UXT contains the following fields: 



Uxt-> Vpi (bits 0 - 1 5 of 1 st wd) = Outgoing VCI or OxFFFF if don't xlate 
Uxt->Vci (bits 16 - 3 1 of 1st wd) = Outgoing VPI or OxFF if don't xlate 
Uxt->Msk (bits 0-31 of 2nd wd) = IP mask if is routed Ci 

Uxt->RtCi (bits 0-13 of 3rd wd) = Ci if being routed 

Uxt->Fwd (bit 14 of 3rd wd) = 1 if currently forwarding AAL-5 cells 

Uxt->Rtd (bit 15 of 3rd wd) = 1 if is routed Ci 

CellXlt conditionally replaces the VPI and VCI fields in outgoing cell header and sends the cell to the Cell 
Interface. CellXlt then calls RlsBi^ in the CellPtrs block, to release the BN back to the Free Queue. 

CeUXlt checks the CellOut FIFO. If the FIFO is not empty, another Ci is and processed. 

5.5. CeU Routing 

PointerSwitch clients in the Mako implementation consist of ATM, TDM, CPU and Scheduler. All but the 
last have a single unique CEd (Client ID). The Scheduler has two Clld's so it can dififerentiate forward and 
backward direction with regard to the Ci as viewed fi'om the external ports of the Ci, For example, consider 
a Ci that is defined between an ATM port and a TDM port. When the Scheduler sends a cell for this Ci to 
the PointerSwitch, there must be a way to know whether it is a cell that came firom the ATM port and now 
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must be sent to the TDM port or vice versa. The duality of Clld*s accomplishes this. 

In Mako, Clld assignments are: 

Clld = 0 for CPU port 
Old =1 for ATM CeU Port 
Clld = 2 for TDM Port 
Clld = 3 or 4 for Scheduler 

As cells pass through Mako, they are processed by various logic blocks. The order in which they are 
processed, i.e. the routing order from block to block, is determined by information in the XT (Switching 
Table). The XT is indexed by Ci. Each XT table element consists of two fields, the first bit, 15, bring the 
scheduler bit saying whether this Ci is to pass through the scheduler, bits 14-0 hold the destination port, 
indicating which port this Ci is to be routed to. The foUowng examples illustrate the fimction of the XT. 

Consider for example a Ci numbered 200 which is to be a simple VC from ATM to TDM port with no QoS 
considerations. The fields in XT[200] are: 

XT[200] = 0, 65 - 1022 where this is any number in the range of TDM ports on Mako 

Consider another example of a Ci numbered 123 between ATM and TDM in which data in both directions is 
to be buffered and paced out to guarantee QoS. 

XT[123] = 1, 65 - 1022 where the 1 indicates that this Ci must pass through the scheduler 

Consider an example of a Ci niunbered 753 between ATM and TDM in wluch Frame Relay is to be buffered 
and paced out to ATM but ATM is to be forwarded directly out to TDM. This would be typical of local 
Frame Relay users connected to a policed public network through ATM. 

XT[753] = 1, 65-1022 

Consider a final example of 0 AM cells being exchanged between ATM and the CPU. 

XT[567] = 0, 1023 where 1023 is the port number of the local port interfece to the CPU. 

S.6. Cell Scheduling 

Note firom WPB: Section 5.6 is undergoing extensive revisions and can be considered a work in progress. 

5.6.1. Introduction 

Cell scheduling (more properly cell sequencing) is performed by the Cell Scheduler 
(CS). The Cell Schedxiler is the distinguishing core of Mako technology. If in the final 
design of the Mako, the Cell Scheduler becomes the pacing bottleneck, then the balance 
of the design has reached their practical limits. The CS will have some variations 
possible but this spec is intended for use in the Dexter 3000. The variations may be a 
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trimming for FRAIM and Dexter 2210 use, with expansion for Dexter 4000 use. All of 
the needed setup calculations and initial setup will need to be performed by the CPU thus 
releasing the CS to do its job without impact on the switching bandwidth. The CS will 
be able to perform pacing (policing) on a per-port basis. It will insert idle cells as 
required. One important provision of the scheduler that should be noted is that ports will 
not intermingile direct switched cell streams with scheduled cell streams. If a single VC 
is scheduled (retimed) for a port all VC's for that port must be scheduled. 

5.6.2. Block Structure of Cell Scheduler and RAM Allocation 

The following diagram is a block representation of the CS. 



Drawing to be inserted when completed. 
Figure 5.6.1 Cell Scheduler Structure 



The following tables show the Cell Scheduler use of internal and external RAM. 



Number of Internal RAM bits (Bytes) 
RAM block 
16,384 bits (2kB) 
17,408 bits (2,176B) 
11,264 bits (1408B) 
131,072 bits(16kB) 
pages) 

128 bits (16B) 



Use of 



2048 bits (0.25kB) 

FREE 34.688 bits 

TOTAL 212.992 bits (26kB) 



Ci status register table (8k x 2 bits) 
Port Status Register (Ik x 17 bits) 
Internal Port Table Entries (32 x 352 bits) 
Internal Bubble Tables (BT) (32 bits x 4096, 128 BT 

Internal Bubble Table Entry Mapping (1 bit x 128) 
External Bubble Table Mapping (1 bit x 2048) 



Table 5.6.1 Cell Scheduler Internal RAM Allocation 



Number of External RAM bits (Bytes) Use of 

RAM block 

1,572,864 bits (192kB) Scheduler Table (ST) (8k x 24 bytes) 

360,448 bits (44kB) Port Table (PT) (Ik x 44 bytes) 

2,097,1 52 bits (256kB) External Bubble Tables (BT) (32 bits x 65.536 each, 

2048 BT pages) 

TOTAL 4,030,464 bits (492kB) 

Table 5.6.2 Cell Scheduler Internal RAM Allocation 
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5,63, Cell Scheduling Algorithm Flow 

The Cell Scheduler Flow and Process diagram is kept in a separate Visio file named 
CSflow.vsd. The detailed discussion that follows refers to this flow diagram. It is 
impractical due to its size and complexity to convert to Word format. It is included in 
this document by reference. There are parallel processes performed for port sequencing 
and Ci activation. In Section 5.6.4 the Ci Activation Process is detailed and discussed. 
In Section 5.6.5 Pre-Scheduling Port Process is detailed and discussed. Finally, in 
Section 5.6.6 Post-Scheduling Port Process is detailed and discussed. These three 
processes run independently and in parallel of the Scheduler thus freeing the scheduler 
for scheduling cells for transmission. This should enhance utilization of available 
bandwidth. 



This flow can be viewed most conveniently as consisting of 13 sub-flows. Many 
functions in the sub-flows are similar but will be performed sequentially and not in 
parallel. The most important part ofthe scheduler is the Bubbler. This flow is designed 
to make the most efficient use of the Bubbler. Table 5.6.3 shows the steps that are 
associated with each sub-flow. 



Sub-fiow function Steps of sub-flow 

CI Activation Steps 1 to 7 

Port Overhead Steps 8 to 13 

QoSPCBR Steps 14 to 16 

QoSCBR Steps 17 to 26 

QoS VBRrt Steps 27 to 39 

QoS VBRnrt Steps 40 to 52 

QoS ABR Steps 53 to 65 

QoS QFC Steps 66 to 82 

QoS ThVBRrt Steps 83 to 92 

QoS ThVBRnrt Steps 93 to 1 02 

QoS ThABR Steps 1 03 to 1 1 2 

QoS UBR Steps 1 1 3 to 122 

QoS Idle Cell Fill Step 123 

Table 5.63 Sub-flow Divisions in Scheduler Flow 

Scheduler Flow is kept in separate Visio file named CSflow.vsd. 

Flow 5.6.1 
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5.6.3.I. 



Step 1 Detailed Description 



This is a simple test to see if there is a Ci requiring activatioa To minimize delays in 
activating Ci's this test is performed every loop through the CS. This can be especially 
critical on data streams that become data starved with every cell transmitted. The Ci 
Activation queue (CiAq) is discussed in precise detail in section 5.6.4 on Ci Activation. 
This step determines if there is an entry in the CiAq. By convention an entry of Ci equal 
to zero will be the same as no entry. If the current entry is equal to zero then no 
increment of the pointer will take place. If there is none, control is passed to the port 
sequencing part of the flow. Step 8. Otherwise control continues on to Step 2. 

5.63.2. Step 2 Detailed Description 

In this step the number of the Ci to be activated is read from the CiAq and the read 
pointer incremented Data on Ci's are contained in 2 places. The first is an internal 
status register table. This table arranged by Ci number is two bits representing the status 
oftheCi. Table 5.6.4 shows the structure of these registers. Bit 0 shows whether the Ci 
is active. The Ci Activation process will set bit 0 when placing a Ci on the CiAq. If 
another cell for the same Ci were to follow, only a single activation will occur. When 
this process sends the last cell in a Ci thread it will clear this bit. QFC Ci's use bit 1. 
This register table will be stored in internal RAM and will use 16kb (16,384 bits) of 
RAM. That's 2 bits for each of 8k Ci's. Bit 1 will indicate that the Ci has been blocked 
because of lack of credit downstream. Bit 1 will stop incoming cells on these Ci's from 
falsely triggering a reactivation of these channels. 



The second place for Ci settings is in the Scheduler Table (ST). Table 5.6.5 shows the 
general structure of an entry in the ST. The first double word functions the same for all 
QoSs. Bits 0-2 are the 3 fractional bits for the Interval Count Bits 3-16 are the integer 
portion of the Interval Count These give us a 14.3 bit resolution. The utilization of 
available bandwidth may be expressed as 1/IC. If IC = 1.0 then 100% of the bandwidth 
is used. If IC = bl.OOl (decimal 1.125) then 88.88...% of the bandwidth is used. At the 
other end if Ci = bl 1 1 1 11 1 1 1 1 1 1 1 1 . 1 1 1 (32767.875) then 0.00306% of the bandwidth is 
used. The value for this number depends on the QoS selected. It is calcidated by 



Bit Number 
1 

QFC-Blocked 



0 

Ci Active 

Table 5.6.4 Internal Ci Status Register Structure 
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software and is critical to the operation of the CS. It should be calculated as close as 
possible then rovmded down tiius rounding up the bandwidth used and ensuring contract 
requirements are met. There are Ik possible ports so bits 17 to 26 are the 10 needed bits 
for the port number of the Ci. Bits 27-29 show the Quality of Service (QoS) for this Ci. 
Table 5.6.6 shows the various QoSs used by Mako. Please note that while there are 1 1 
listed QoSs, only 7 values are used for the QoS value. Only the Port Status Register and 
Bubble Tables use the ftrottled QoSs. Bits 30 and 31 are imused at the present time. 
The ST is kept in external RAM and is indexed by Ci number. There are 8k possible 
Ci's and each entry in the ST uses 24 bytes, therefore the ST will use 192kB of external 
RAM. 



BIT NUMBER 

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 1211 10 9 8 7 6 5 4 3 2 
1 0 

Unused QoS Port Number 

Integer Portion of Interval Count Fractional Portion of Interval Count 

Use of these registers varies by QoS detailed In section on each QoS. 
Use of these registers varies by QoS detailed in section on each QoS. 

Table 5.6.5 General ST Register Structure 

QoS Value (Binary, Decimal) QoS 

Pacing Constant Bit Rate (PCBI^ forced idles) 
Constant Bit Rate (CBR) 
Variable Bit Rate, real time (VBRrt) 
Variable Bit Rate, non-real time (VBRnrt) 
Available Bit Rate (ABR) 
Quantum Flow Control (QFC) 
ThrotUed VBRrt Ci's (ThVBRrt) 
Throttled VBRnrt Ci's (ThVBRnrt) 
ThrotUed ABR Ci's (ThABR) 
Unspecified Bit Rate (UBR) 
Idle Cell Rller. added by state machine 

Table 5.6.6 Available Qualities of Service (QoSs) 

There are 3 types of QoSs listed that are not industry standard and are unique to Mako. 
The first is the Pacing Constant Bit Rate (PCBR). A PCBR Ci is used to force idle cells 
on an active port to limit the use of available bandwidth. An example of this could be 
when the physical connection is a Tl 1.554Mb connection and the user is only paying for 
half the bandwidth. The PCBR would force idle cells every other cell thus pacing the 
port to 50%. These Ci's will set up like any others except they will be activated 
whenever the port becomes active and not througji the CiAq. If there are no active Ci's, 



QoS Priority 


Name 




1 


000,0 


2 


001,1 


3 


010,2 


4 


011,3 


5 


100,4 


6 


101,5 


r 


010, 2-A 


8 


Oil, 3-A 


9 


100, 4-A 


10 


110,6 


11 


Implied 
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thus rendering the port inactive, then the physical layer will fill with all idle cells by 
default and PCBR is not needed. Sending PCBR cells and idle fill cells advance the Port 
Increment Counter and advance the conditions for unthrottling. The PCBR is a special 
case in that a combination of up to 3 Ci's may be used to get the finest possible 
resolution on the pacing value. This cannot be done with other Ci's, as only a single cell 
stream is manageable and available, with PCBR the cell stream is all idle cells. 

The second unique case QoS is for throttled Ci's, These Ci's have sent their guaranteed 
number of cells per time measurement unit These are VBR and ABR Ci's. These Ci's 
have been moved to lower priority thus giving CBR and unthrottled Ci's more of the 
available bandwidth (higher priority). Under QFC there is a credit/debit system that 
when exhausted that causes the Ci to be blocked (deactivated) rather than throttled. The 
time measurement unit will be set between 1/8 and 1/4 of a second and the appropriate 
number of guaranteed cells set Every time a cell is sent this number is decremented in 
the Ci's register. When zero is reached the Ci will be removed from the unthrottled QoS 
BT and placed in the throttled QoS BT, Cells are then sent over the switch at the new 
lower priority. When the time measure coimter resets to zero these Ci's will be 
unthrottled and placed back in the correct QoS to schedule cells once again. This 
unthrottling is explained in Step 13. 

The third and final special case QoS is the implied Idle Cell Filler. This QoS has no 
assigned Ci number. When a port is active and there are no other cells ready to be sent, 
then this QoS inserts an idle cell to maintain the bandwidth integrity of the port. This is 
especially important on ports with only active CBR Ci's. If there were no idle cell filler 
then the port would over schedule the CBR Ci's. 

5.6.3.3. Step 3 Detailed Description 

This step uses the port number of the activating Ci and checks to see if the port is active 
by checking the port active bit in the Port Status Register. If the port is active Step 4 is 
bypassed and control transferred to Step 5. If the port is not active then control is passed 
to Step 4. 

5.6.3.4. Step 4 Detailed Description 

This step does not activate the Ci but rather prepares a given port for Ci activation. For a 
port to be inactive it means that there was no data available for any of the port's Ci's. 
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This step will activate the port by setting the port active flag and activating any PCBR 
Ci's that may be associated with the port. In internal RAM there shall be a Port Status 
Register. This register has 16 bits for each port. Since there Ik ports this will use 16kb 
(16,384 bits) of internal RAM. The structure of these status registers is shown in Table 
5.6.7. Bit 15 is set for an active port. Bits 5 to 14 are set to show which QoSs have 
active Ci's. Bit 4 is set when the FT entry has been transferred to internal RAM. There 
will be 16 available spaces in internal RAM for PT entries, so bits 0 through 3 (4 bits) 
will be used for addressing. Each entry uses 352 bits, therefore all 16 stored entries will 
use 5,632 bits of internal RAM All entries will be also be stored in external RAM 
Each entry will use 44 bytes and there are Ik maximum ports, therefore the PT will use 
44k bytes of the external RAM Since a port is being activated here there will be no pre- 
loading of the port entry but rather a read from external RAM In this step the Port 
Active bit is set. The Port Interval Counter will not be reset. This is important to 
maintain bandwidth integrity for bursty traffic. When a port is first setup by software it 
is important to set the PIC to zero giving the port a uniform place to begin processing 
cells. Any PCBR Ci's are activated. They should activated with target times equal to the 
PIC. This forces the PCBR Ci's to start sending idle cells first before other Ci's thus 
enforcing pacing requirements from the beginning. The reason the PIC is more than 14 
bits is to allow for scaling on the time measurement unit on ports of various speeds. This 
scaling factor is in terms of bits from 14 to get a time measurement unit between 1/8 and 
1/4 of a second. Table 5.6.8 shows the structure of an entry in the PT. Please note the 
maximum number of active Ci's for a single port's QoS is 1,023 (Ik - 1) or 10 bits. It 
will place the appropriate addresses for first Ci of a QoS reading. When the CS is 
checking for ready cells this base address will have the target time for the highest priority 
Ci for a particular Ci and can be used for a fast check for ready to send status. The PT 
entry should be retained in internal registers for the next step. 

BIT NUMBER 

16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Port Active PCBR QoS Active CBR QoS Active VBRrt QoS Active 

VBRnrt QoS Active ABR QoS Active QFC QoS Active 

Tlirottied VBRrt QoS Active Throttied VBRnrt QoS Active 

Throttied ABR QoS Active UBR QoS Active Internal RAM Used 

Port Table Internal RAM location 

Table 5.6.7 Port Status Register 

BIT NUMBER 

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 10 
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Double Word Number 

0 Signed Scaling Factor for Time Measure Unit 
Port Interval Counter (PIC) 

1 Number of PCBR Ci's Located in Internal RAM 
Base Address of this PCBR Queue 

2 Number of CBR Ci's Base Address of this CBR Queue 

3 Number of VBRrt Ci's 

Base Address of this VBRrt Queue 

4 Number of VBRnrt Ci's 

Base Address of this VBRnrt Queue 

5 Number of ABR Ci's Base Address of this ABR Queue 

6 Number of QFC Ci's Base Address of this QFC Queue 

7 Number of ThVBRrt Ci's 

Base Address of this ThVBRrt Queue 

8 Number of ThVBRnrt Ci's 

Base Address of this ThVBRnrt Queue 

9 Number of ThABR Ci's 

Base Address of this ThABR Queue 

10 Number of UBR Ci's 
Base Address of this UBR Queue 

Table 5.6.8 Structure of Port Table Entry 

5.6 J.5. Step 5 Detailed Description 

This step checks the QoS active bit in the Port Status Register to see if this QoS is set 
active. If the bit is already set, the flow goes to Step 7. If this bit is set inactive then the 
flow goes to Step 6. 

5.6.3.6. Step 6 Detailed Description 

This step sets the QoS active bit active. 

5.63.7. Step 7 Detailed Description 

The QoS BT will be loaded into the Bubbler. This can be either from internal or external 
RAM depending on the data provided in the PT (there is a possibility that BT has been 
retained in internal RAM). The Bubbler will then insert the newly activated Ci at the 
front of the BT, with a Target Time equal to the current PIC for this port. Table 5.6.9 
shows the structure of a BT entry. There is one for every active Ci. The Bubbler 
Processor places it in the proper position. The internal Bubbler will have 32 entries. 
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Internal RAM will require the use of Ikb (32 entries times 32 bits) for each Bubbler 
page. The discussions on the Pre and Post Port Processing will show how external RAM 
and internal RAM are used to coordinate these Bubble sections. The PT entry sho\ild be 
updated (this includes incrementing the QoS active Ci count and adjvisting the base of 
address(es) of the QoS queues as needed.) to show the newly activated Ci and copied to 
external RAM. 

BIT NUMBER 

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 

16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Overflow & Carry Integer Target Time 

Fractional Target Time Ci Number 

Table 5.6.9 Structure of Bubble Table (BT) Entry 

5.6.3.8, Step 8 Detailed Description 

Step 8 gets the next port number to be scheduled jfrom the Port Queue (PQ) and advances 
the pointer. The PQ is FIFO that gets its entries from the Pre-Scheduling Port Processor. 
This means that the entries on the PQ have been pre-qualified and are known to active. 
If the Pre-Scheduling Port Processor has not qualifies any port as active the value here 
will be zero and control then passes onto Step 1. If the port number is anything but zero 
control passes to Step 9. 

5.6.3.9. Step 9 Detailed Description 

The first thing done here is the loading of the Port Register from RAM to the local 
working register. The Port Status register will tell if this must be done from external 
RAM or can be done from internal RAM. If a port is active then some type of cell will 
be sent to the Switch. This means the Port Increment Counter will be advanced. This 
step does that incrementing in the loaded port register. 

5.6 J.IO. Step 10 DetaUed Description 

This step checks to see if the PIC overflowed. An overflow condition would be that bits 
0 through 13 would be all set to zero. An overflow would not occur on a newly activated 
port since the all zeros of such a port would have been incremented to 1. If this 
condition is true then control passes to Step 10 otherwise the process continues to Step 
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11. 



5.6.3.11. Step 11 Detailed Description 

All active Ci's for QoS numbers 1 through 7 are loaded into the Bubbler and the 
overflow and carry bits are reduced by 01. This will maintain the proper sequence and 
value for these Ci's now that the PIC has overflowed Control continues on to Step 12. 

5.6.3.12. Step 12 Detailed Description 

This step will use the scaling factor in the port entry table to determine if the Time 
Measure Counter has overflowed. The scaling factor reduces or enlarges the number of 
bits checked for all O's. If the scaling factor is set to zero then the Time Measure 
Counter is equal to 14 bits the same as PIC overflow. If the scaling factor were -5 then 
only bits 0-8 need to be zero, or 9 bits. Conversely the scaling factor may be as large as 
+13 meanmg that 27 bits (0-26) of the PIC would need to be equal to 0. This would be a 
very fast port where many cells would need to be sent to meet the 1/8 to 1/4 of a second 
requirement Using El as a first example: El sends 5333.33 cells of data per second 
The 14-bit overflow would represent 16.384 (214) cells. This would be over 3 seconds 
worth of cells. This is too long for effective throttling. In 0.125 seconds El would send 
666.63 cells and in 0.25 seconds 1333.33 cells. The binary value in this range is 1024 or 
210. For El the scaling factor would be -4 and a time measure unit of 0.192 seconds. 
When calculating the maximum number of cells before throttling it should be based on 
this penod of time. Using E4 as an example at the other end: E4 sends 364,583.33 cells 
per second. The 14-bit overflow would represent 0.04494 seconds. This is far too little 
for effective throttling. In 0.125 seconds E4 would send 45,572.92 cells and in 0.25 
second 91,145.83 cells. The binary number in this range is 216 or 65,536. The E4 
scaling factor would then become +2. The time measure period would then be 0.1798 
seconds. 

5.63.13. Step 13 Detailed Description 

In this step the Ci's in the three throttled QoS queues will be moved to the appropriate 
unthrottled QoS queues. The Port Status Register needs to be updated to reflect any 
changes made. 

5.6.3.14. Step 14 Detailed Description 
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Step 14 checks for a greater than zero value in the number of PCBR Ci's in the Port 
Table register. If this number is zero then control passes on to Step 16. A number other 
than zero passes control on to Step 14. This is check for the highest possible priority 
QoS thus ensuring that PCBR cells are switched in preference to any other QoS. 

5.63.15. Step 14 Detailed Description 

Using the base address in the Port Entry register the Target Time value for the first 
PCBR Ci is compared to the PIC. If the integral portion is equal or smaller then the Ci is 
ready to be sent. If true then control passes to Step 18. If false then control moves on to 
Step 16. 

5.6.3.16. Step 15 Detailed Description 

A PCBR Ci is passed to the switch in a special maimer. It is always an idle cell. The 
switch receives an idle cell request with the port number instead of the Ci number. The 
Interval Time for this Ci is added to the Target Time and bubbled back into the BT. 
Control passes to Step 1. 

5.63.17. Step 16 Detailed Description 

This step checks for active CBR Ci's. This is done by reading the number of CBR Ci's 
in the Port Table register. If the number is zero control passes to Step 24. If there are 
active CBR Ci's then control passes to Step 17. 

5.63.18. Step 17 Detailed Description 

Using the base address of the CBR Queue the Target Time is compared with the PIC. If 
this Ci is ready to send then control passes to Step 18, if not control is passed to Step 24. 
5.6.3.19. Step 18 Detailed Description 

This step sends this Ci to the Switch. Control passes to Step 19. 

5.63.20. Step 19 Detailed Description 

This step checks to see if this is the last cell on the Ci thread. If it is control passes to 
Step 20, if not control passes to Step 23. 

5.63.21. Step 20 Detailed Description 

The Ci is removed fi-om the BT for this port This deactivation is because the Ci has 
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become data starved It wiU be reactivated again by the Port Activation Process when 
another cell becomes available for switching. Control is passed to Step 21. 
5.6.3.22. Step 21 Detailed Description 

This step scans for a nonzero value in any of the number of active Ci's for QoSs 1 to 15. 
If there is a nonzero value then control passes to Step 1. If all values are zero then 
control passes to Step 22. 

5.63.23. Step 22 Detailed Description 

The Port is deactivated. Control Passes to Step 1. 

5.6.3.24. Step 23 Detailed Description 

The Interval Time is added to the Target Time and bubbled back into the BT. The Port 
Entry Table is copied back into RAM. 

5.6.3.25. Step 24 Detailed Description 

The number of active VBRrt Ci's is read from the Port Table register. If the value is zero 
control is passed to Step 36, if not control is passed to Step 25. 

5.63.26. Step 25 Detailed Description 

Using the Base Address in the Port Entry register the Target Time for the first VBRrt Ci 
is checked, if less than the PIC then control is passed to Step 26. If the cell is not ready 
then control passes to Step 36. 

5.63.27. Step 26 Detailed Description 

The Ci number is sent to the Switch. Control passes to Step 27. 

5.63.28. Step 27 Detailed Description 

This step checks to see if this was the last cell in the Ci thread. If it was then control 
passes to Step 28, if not then control passes to Step 31. 

5.63.29. Step 28 Detailed Description 

This Ci has become data starved and is removed from the BT. Control passes to Step 29. 
5.6330. Step 29 Detailed Description 

This step scans for a nonzero value in any of the number of active Ci's for QoSs 1 to 15. 
If there is a nonzero value then control passes to Step 1. If all values are zero then 
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control passes to Step 30. 

5.63.31. Step 30 Detailed Description 

The Port is deactivated Control passes to Step 1. 
5.6.332. Step 31 Detailed Description 

The Ci is still active and is checked to see if the Ci is subject to throtding. If it is then 
control is passed to Step 32, if not then control is passed to Step 35. 
5.6333. Step 32 Detailed Description 

Table 5.6. 10 shows the structure of the ST entry for a VBRrt entry. There is entry here 
that is calculated using the PIC and Time Measure Scaling Factor. This is the Time 
Measure Period Count This 6-bit count is the bits more significant than the Time 
Measure Count overflow. When overflow occurs on die Time Measure Period there is 
no resetting for active unthrottled Ci's. This value accomplishes this needed process. 
The first check in this step is this value. If it is not equal to the current value from the 
PIC, then it is set to the PIC value and the number of cells sent is forced tol. This means 
the Time Measure Period is new and this is the first cell sent by this Ci during it. If the 
values are equal then the Sent value is incremented by 1. Control is passed to Step 33. 

BIT NUMBER 

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 1211 10 9 8 7 6 5 4 3 2 
1 0 

Throttle Throttled QoS 

Port Number Integer Portion of Interval Count 
Fractional Portion of interval Count 

Maximum Numlier of Cells per Time Measure Period to Send 
Time Measure Period Count 

Number of Cells Sent Current Time Measure Period 
Table 5.6.10 STE Register Structure for VBRrt 
5.63.34. Step 33 DetaUed Description 

The 2 values of the maximum number to be sent is compared with the number sent. If 
the number sent is equal to or grater than the maximum number control passes to Step 
34, if not control passes to Step 35. 
5.6335. Step 34 Detailed Description 

The Ci is throttled by moving it from the active QoS to the throttled QoS. Control Passes 
to Step 1. 

5.6.3.36. Step 35 Detailed Description 
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The Interval Time is added to the Target Time and bubble back into the BT. Control 
passes to Step 1. 

5.6.4. Ci Activation Process 

The following diagrams the flow of the Ci Activation Process. This process actually 
qualifies Ci's for activation by the Scheduler. Already active and blocked Ci's are 
ignored. The sections following give a detailed description of the steps in this process. 
This flow is also in the Visio file CiActvsd. 



Flow 5.6,2 Flow for Ci Activation Qualification 

5.6.4.1. Step 1 Detailed Description 

This is the default idle state for the process. It waits for an alert from the Switch Queue 
(QSw) or for the CiAq to go from full to non-fiill. The QSw has a list of Ci's that have 
had cells switched to the scheduler. If a Ci needs activation it will be place on the CiAq 
so there is a check to insure there is a place for the entry. 

5.6.4.2. Step 2 Detailed Description 

This step removes an entry from QSw. It is placed in the register CqCi. 

5.6.4.3. Step 3 Detailed Description 

The status bits of the Ci are checked to see if it is already active or blocked. If it is either 
then control transfers to Step 1 else control passes to Step 4. 

5.6.4.4. Step 4 Detailed Description 

The Ci is added to the CiAq FIFO and the active bit for the Ci is set 
5.7. Frame Segmentation 

Frame Relay data coming in through a Tl/El port is multiplexed by a Line Inter&ce Unit (LIU) onto a TDM 
highway. 16 Tl/El ports are allowed. Each LIU can handle 32 channels. This yields 512 channels. 
Information about each channel is stored in the TST (Time Slot Table). The table has 512 entries with each 
entiy being 76-bits wide. The TST is indexed by the key (Port + Channel + DLCI). Each entry has the 
following fields: 
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Status (3 bits) 

Ci (or header bytes) (1 1 bits) 
Offset (6 bits) 
Frame checksum (16 bits) 
AAL5 checksum (32 bits) 
Byte fragment (8 bits) 

The status field is defined as: 



0 idle 

1 sync 

2 1st byte header 

3 2nd byte header 

4 3rd byte header 

5 4th byte header 

6 payload 

7 bonding base 



(open question: are. idles in frames allowed?) 

TdmRes block correlates an incoming firame to a defined Ci and passes the Ci to TdmSeg. It does this by 
searching for the DLCI and source port number of the incoming fi^e in the TDM Resolution Table (TRT). 
Each element in the TRT contains the following fields: 

TrtDlci contains the DLCI of the Ci. 
TrtPort contains the source port of the Ci. 
TrtChan contains the source channel of the Ci. 
TrtCi contains the Ci. 

Elements in the TRT are ordered by the first two fields which serve as the search key. TdmRes performs a 
binary search in an attempt to match the incoming DLCI and port number to an TRT entiy. If the entry is 
found, the incoming firame is discarded and the UnkFnn counter is incremented. If a match is found, the Ci is 
passed to the TdmSeg block. 

Frame Relay firagmentation and reassembly, recommended but optional in the FRF8 specification, are not 
supported. 

TdmSeg reads the TxCi entry from the entry in the TDM Translation Table (TXT) indexed by Ci. If the 
mode is FRF5, the following happens: if TxBecn is set, the BECN field is set in the incoming Frame Relay 
header, depending on TxClp, the CLP bit is copied from the Frame Relay DE field or set to 0 or set to 1 in 
each cell; the Frame Relay PDU is segmented directly into an AAI^5 cell stream. If the mode is FRF8 
transparent. No change is made to the Frame Header and the Frame PDU is segmented directly into an 
AAL-5 cell stream. If the mode is FRF8 translation then the first sfac bytes of the Frame Relay header are 
used in a simple decision tree for form an appropriate header prepended to the AAL-5 PDU. 
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TrmSeg calk the GetBf routine in the CellPtrs block to get a BN for each celL TdmSeg reads frame payload 
from the Frame Interface and stores it in the BPld buffers associated with the EhPs. 

Only one frame can ingress through the Frame Interfece at a time so TrmSeg is not required to interleave 
between frames. 

TrmSeg presents its CUd and a Ci to the PointerSwitch. The PointerSwitch virtuaUy switches ceUs to their 
next destination. The next destmation may be any client. 

5.8. Frame Reassembly 

The TrmReas block receives Ci's from the PointerSwitch block. On receipt of a Ci, TrmReas fetches its 
CiPtr, gets the BN from CiOut and examines the corresponding BPld to see whether it is the last cell of a 
frame. If it is not the last ceU of a frame, TrmReas does nothing more. If it is the last ceD of a fi^e, 
TrmReas adds Ci and EFQ information into the TrmOut FIFO. Each element in the TrmOut FIFO contains 
the following fields: 

TxCi contains the Ci to \^ch the cell applies. 

TxCiBecn indicates whether the EFCI bit was set in the header of the cell in BPld. 

If the TrmOut FIFO is not empty, TrmReas removes the first entry. The entry in the TDM Translation Table 
(TXT) indexed by TxCi is fetched which contains the following fields: 

TxMode contains an mdicator of encapsulating mode according to the following values: 

0 = FRF5 encapsulation 

1 = FRF8 transparent mode 

2 = FRF8 translation mode 

TxBecn indicates \^ether the last outgoing fi::ame on the Ci had its BECN field set. 
TxHdr contains 4 bytes of Frame Relay header. 

TxDe indicates whether ATM CLP information goes into the FRF5 Frame Relay DE field. 
TxClp indicates whether the ATM CLP is set from the FRF5 Frame Relay DE field or to 0 or to 1 . 

If TxMode is FRF5 encapsulation, the AAL-5 PDU is reassembled into a Frame Relay PDU, the DE field is 
set according to TxDe and the FECN bit is set according to TxCiBecn and the fi^e is sent to the Frame 
Interfece. 

As the cells are taken from the CiPtr queue, TdmReas calls the RlsBf routine in the CellPtrs block to return 
their BN^s back to the FreeQ. 

When the Frame is completely sent to the Frame Interfece, TrmReas again checks the TrmOut FIFO. If the 
FIFO is not empty, another frame is extracted from its CiPtr, processed and sent to the TDM Interface. Note 
that this process allows TrmReas to completely process one Frame at a time so it is not required to 
interleave between fi^es. 
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6. Data Structures 



The operations described in the previous s«:tion perform operations on a set of data tables. These tables 
sununarized below. 



Port Numbers 
0 

1-64 
65 - 1022 
1023 



Port Type 
Scheduler 
Utopia PHY 
TDM 
Local Port 



Qient Number 

0 

1 

2 

3.4 



Oicnt Type 

CPU 

ATM 

TDM 

Scheduler 



Description of Time Slot Table (TST) 

The Time Slot Table (TST) is indexed by channel (port) number. There are a total of 512 channels, 
organized as 16 ports times 32 channels. Each entry in the table is composed of the foUowing fields: 

Status (3-bits) 
0=idle 
l=sync 

2=lst byte header 

3=2nd byte header 

4 =3rd byte header 

5==4th byte header 

6=payload 

7=bonding base 
Ci (or header bytes) 
Ofi&et 

Frame checksum 
AAL5 checksum 
Byte Augment 



Tables sorted by key 



Table 



URT 
TRT 



Register 
UrtBase 
TrtBase 



Width 
44b 
42 b 



Estimated Size 
10 KB 
10 KB 



Tables indexed by Ci 



Table 



CiPtr 

UXT 

TXT 

ST 

XT 



Register 
CiPtrBase 
UxtBase 
TjrtBase 
StBase 
XtBase 



Width 
64b 
28 b 
44b 
51b 
24b 



Estimated Size 

10KB 

6KB 

12 KB 

10 KB 

6KB 
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Tables indexed by Channel (Port) Number 

TST TstBase 



5KB 



Tables indexed by BN 

'^^^^ Register Width Estimated Size 

BPtr BptrBase 12 6 KB 

BPld BpldBase 52 156 KB 

FIFO 

The FIFO are stored in off-chip RAM The FIFO sizes will be decided after simulation. 

Width Estimated Size 

TrmOut I6b TBD 

PktOut 16b TBD 

CeUOut 16b TBD 

LocalOut 16b TBD 

?• Interface Signals 

Mako wiB initially be packaged in an FPGA with attached SDRAM. The following table defines interface 
signals on the FPGA, 

Pin(s) I/O Signal Name Description 

I Clk Mako dock 

I Rst_n Mako reset (0=reset) 

I RegRwEnb Register access enable; l=enable, 0=disable 

I RegAddrS^ Register address (bits 5-0) 

I RegRwMode Register read/write mode; l==Tead, 0=write 

I AnnWait_n Register read wait; l=inhibit read, 0=read 

I/O RegData Register data (bits 3 1-0) 

0 DbgReg Debug register (bits 3 1-0) 

1 IntRq Intemipt request 

I RA19-RA0 SRAM address (bits 19-0) 

I/O RD3 1-RDO SRAM data (bits 3 1-0) 
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RE0-RE3 


rrrm 


TlTxClk 


TDM mterfece 1 transmit clock 


TlTxSync 


TDM mterfece 1 transmit sync 


TlTxDat 


TDM interface 1 transmit data 


TlRxClk 


TDM interfece 1 receive clock 


TlRxSync 


TDM interfece 1 receive sync 


TlTxDat 


TDM interfece 1 receive data 


T2TxClk 


TDM interfece 2 transmit clock 


T2TxSync 


TDM interfece 2 transmit sync 


T2TxDat 


TDM interfece 2 transmit data 


T2RxClk 


TDM interface 2 receive clock 


T2RxSync 


TDM interfece 2 receive sync 


T2TxDat 


TDM interfece 2 receive data 


UlTxCIk 


Utopia-2 interfece 1 transmit clock 


UlTxClAv 


Utopia-2 interfece 1 transmit cell available 


UlTxDatO-7 


Utopia-2 interfece 1 transmit data (7-0) 


UlTxEnb 


Utopia-2 interfece 1 transmit enable 


UlTxPhyO-3 




UlTxSoc 


Utopia-2 interfece 1 transmit start-of-cell 


UlRxClk 


Utopia-2 mterfece 1 receive clock 


UlRxClAv 


Utopia-2 interfece 1 receive cell available 


UlRxDatO-7 


Utopia-2 interfece 1 receive data (7-0) 


UlRxEnb 


UtODia-2 interfkcf^ 1 rpcpivf^ pnaVilo 


UlRxPhyO.3 




UlRxSoc 


Utopia-2 interfece 1 receive start-of-cell 


U2TxClk 


Utopia-2 interfece 2 transmit clock 
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U2TxClAv 


Utopia-2 


inter&ce 


2 transmit cell available 


U2TxDat0.7 


Utopia-2 


interface 


2 transmit data (7-0) 


U2TxEnb 


Utopia-2 


interface 


2 transmit enable 


U2TxPhyO-4 








U2TxSoc 


Utopia-2 


interface 


2 transnut start-of-cell 


U2RxClk 


Utopia-2 


inter&ce 


2 receive clock 


U2RxClAv 


Utopia-2 


inter&ce 


2 receive cell available 


U2RxDatO-7 


Utopia-2 


interfece 


2 receive data (7-0) 


U2RxEnb 


Utopia-2 


interface 


2 receive enable 


U2RxPhyO-4 


Utopia-2 


inter&ce 


2 phy 0-4 select 


U2RxSoc 


Utopia-2 


inter&ce 


2 receive start-of-cell 



8. Interface Registers 

Registers in Mako vaiy in size fixjm 8 bits to 32 bits. Outside of Mako, registers appear as 32-bit values. 
To the ARM processor, Mako registers are memoiy-mapped. Access to the registers is via the foUowing 
three items: 

MakoRWMode specifies if a re^ster is to be read or written. A * 1' denotes a read operation. 
MakoRegEnab specifies that a register is to be accessed. A ' T is an enabling condition. 
The Command Register (0x00) contains the register number to be accessed. 
ArmWait_n, when low causes Mako to ignore read/write requests. 
Mako contains the following interface registers: 



Offset 

0x00 


Function 
Read 


Name 

Version 


Description 

Version nimiber 


0x00 


Write 


Command 


Command Register 


0x01 


ReadAVrite 


RamAdr 


Auto-incrementing RAM address pointer 


0x02 


Read/Write 


RamDat 


RAM data 


0x03 


Read/Write 


BptrBase 


Address of first BPtr 
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0x04 


Read/Write 


RnlrfRace 

UUlVLDOoC 


Afloress ot tirst oFla 


0x05 


ReadAVrite 


PfPtrRflop 


Auuress ot nrst Cirtr 


0x06 


ReadAVrite 


yvioooC 


Address of first XT entry 


0x07 


Read/Write 




Address of first ST entry 


0x08 


ReadAVrite 


TitRflce 


Aoaress or iirst BT entry 


0x09 


ReadAVrite 


TTrtT^aci^ 
LOfloC 


Aaoress oi nrst URT entry 


OxOA 


ReadAVrite 


PellOiitDacf^ 


Aoaress or nrst CellOut FIFO entry 


OxOB 


ReadAVrite 




Address ot nrst UXT entry 


OxOC 


ReadAVrite 


UlLDaoC 


Address ot first FRT entry 


OxOD 


Read/Write 




Address ot first TdmlUut FIFO entry 


OxOE 


ReadAVrite 




Address of first FXT entry 


OxOF 


ReadAVrite 


ox OdoC 


Address ot first Scheduler Register Pointer block 


0x10 


RejiHAVrite 


xsioase 


Address ot first Frame Channel entry 


0x11 


RejidAVrite 

fVCcUl/ TV lllC 


iNuinuix 


Wumber of URT entries 


0x12 


ReadAVrite 

XVeOU/ TT 1 lie 


IWt It'l^ 


iNumber ot FRT entnes 


0x13 


ReadAVrite 


FreeOFr^ 

X leeX^X 131 


rirsi iree ois 


0x14 


ReadAVrite 


X lCCV^X.«<ldl 


i.«asi iree op* 


0x15 


ReadAVrite 




Most significant 32 bits of Search Key&Ci 


0x16 


ReadAVrite 




i^east signincant 32 bits ot bearch Key&Ci 


0x17 


Read/Write 


IntStat 


imci I up I siaius 


0x18 


ReadAVrite 

XX^CmV TT 1 lie 


Tnt'M'Qlr 


inxemipi enaoie mask 


0x19 


ReadAVrite 

XXWdU/ TT I lie 


UiUUrlUi 


Counter of Frames with unrecognized DLCI & port 


OxlA 


Read/Write 


RaHFrm 

X^ClvXL 1 111 


v^ounicr oi rrames wiin v^KC errors 


OxlB 


ReadAVrite 


OvfFrm 


Counter of Frames lost due to buffer overflow 


OxlC 


ReadAVrite 


UnkCeU 


Counter of Cells with unrecognized DLCI & port 


OxlD 


ReadAVrite 


BadCeU 


Counter of Cells with CRC errors 



135 



OxlE 


ReadAVrite 


OvfCell 


\^ounier oi v^eiis lost due to Duner overflow 


OxlF 






(unassigned) 


0x20 


ix^au/ VT 1 lie 




Utopia Configuration 


0x21 


xvcau/ TV 1 lie 


r^qiD ase 




0x22 




jroioase 




0x23 


ReadAVrite 


TDMRitFrr 




0x24 


ReadAVrite 


Led 




0x25 


ReadAVrite 


PtFnTn 


x^on rree v^eue 


0x26 


ReadAVrite 


PtFqOut 


Port Free Queue 


0x27 


ReadAVrite 


CiFqIn 


Ci Free Queue 


0x28 


ReadAVrite 
ReadAVrite 


CiFqOut 


Ci Free Queue 



8.1. Version Register (0x00) 

The Mako Veraojire^ster is an 8-bit read-only register. It reflects the design version of Mako. The initial 
version number will be a binary 'OOOOOOOl* and will be incremented by one for each subsequent revision. 

8.2. Command Register (0x00) 

The Command Re^ster is a 32-bit wiite-only re^er which specifies which one of the Mako registers is to 
be read/written. Setting bit 0 specifies that registw 0 is to be accessed. The MakoRegEnab signal, if high, 
specifies that the register specified by the Command Register can be accessed. The MakoRWMode signal, if 
high, specifies that the regster is to be read. The bits m the Command Register are mutually exchisive. Only 
one bit should be set. Unpredictable results may occur if more than one bit is set to a one at the same time. 

83. RamAdr Register (0x01) 

RamAdr is a 32-bit memory address in the external SDRAM. 

8.4. RamDat Register (0x02) 

RamDat is a 32-bit register with data to be written to the x32 SDRAM 

8.5. BPtrBase (0x03) 

BptrBase is a 32-bit address of the BPtr table in SDRAM 



136 



8.6. BPldBase (0x04) 

BpldBase is the 32-bit address of the start of the BPld table in SDRAM. 

8.7. CiPtrBase (0x05) 

CiPtrBase is the 324>it address of the start of the CiPtr table in SDRAM. 

8.8. XtBase(0x06) 

XtBase is the 32-bit address of the start of tiie 3Q table in SDRAM 

8.9. StBase(0x07) 

StBase is the 32-bit address of the start of the St table m SDRAM. 

8.10. BtBase (0x08) 

BtBase is the 32-bit address of the start of the Bt table in SDRAM 

8.11. UrtBase (0x09) 

UrtBase is the 32-bit address of the start of the URT table. 

8.12. CellOutBase (OxOA) 

8.13. UxtBase (OxOB) 

8.14. TrtBase (OxOC) 

8.15. TdmOutBase (OxOD) 

8.16. TxtBase (OxOE) 

8.17. SPBase (OxOF) 

8.18. TstBase (0x10) 

8.19. NumUrt(Oxll) 

Number of entries in the URT table. This is a 16-bit quantity. 

8.20. NumFrt (0x12) 

Number of entries in the FRT table. This is a 16-bit quantity. 
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8.21. FreeQFrst (0x13) 

FreeQFrst is the entry number of the first firee buflFer in BN. This is a 16-bit quantity. 

8.22. FreeQLast (0x14) 

FreeQLast is the entry number of the last firee buffer in BN. This is a 16-bit quantity. 

8.23. KeyMs (0x15) 

8.24. keyLs(0xl6) 

8.25. IntStat Register 

The IntStat Register contains event flip-flops which are set on occurrence of significant system events 
InStat IS an 8-bit register with the bits defined in the table below. 

Bit Description 

0 Unknown fiame count >= 1 28 

1 Bad fi^e count >= 128 

2 Overflow fitune count >= 128 

3 Unknown cell count >= 1 28 

4 Bad cell count >= 128 

5 Overflow cell count >= 128 

8.26. IntMsk Register 

The IntMsk Register bits correspond with the interrupt event bits in the IntStat register and control the 
abihty of specific events to generate a Mako interrupt to the Host CPU. Each bit in the IntMsk Register is 
logically and ed with the coixesponding bit in the IntStat Register. If the result is non-zero then the interrupt 
request will be passed to the Host 

8.27. UnkFrm Register 

The UnkFrm register is an 8 bit counter of the number of frames discarded because their DLCI and Port 
d«ta^ correspond to any defined VC. It sticks at aU I's. It clears to all O's after bemg read through the CPU 
mterface. A maskable mtenupt request bit is set when the count reaches 128. This gives the software time 
to react and read the count before the error count reaches 255. If the count reaches 255. it will remain at 255 
until read by the CPU regardless of the number of additional error events. 

8.28. BadFrm Register (OxlA) 

The BadFrm register is an 8 bit counter of the number of fiames discarded because CRC was incorrect. It 
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sticks at an Vs, It clears to all O's after being read through the CPU interfece. 

8.29. OvfFrm Register (OxlB) 

The OvfFrm register is an 8 bit counter of the number of frames discarded because there were no buffers to 
hold them. It sticks at all I's. It clears to all 0*8 after bring read through the CPU interface, 

830. UnkCell Register (OxlC) 

The UnkCell register is an 8 bit counter of the number of cells discarded because their VPI. VCI and the 
most significant bit of their PTI didn*t correspond to any defined VC. It sticks at all Vs. It clears to all O's 
after being read through the CPU interfece. 

8 Jl. BadCeU Register (OxlD) 

The BadCell re^ster is an 8 bit counter of the number of cells discarded because HEC was incorrect. It 
sticks at all I's. It clears to all O's after being read through the CPU interfece. 

832. OvfCeU Register (OxlE) 

The OvfCell register is an 8 bit counter of the number of cells discarded because there were no bujBfers to 
hold them. It sticks at all Vs. It clears to all O's after being read through the CPU interface. 

833. UtCfg Register (OxlF) 

The UtCfg register is a 32 bit register that controls the configuration of the Utopia ports. The fimctions of 
the various fields within UtCfg are described in the following table. 



Bit(s) Description 

^ " ^ Utopia PHY number. This field is ignored if the Utopia is a master or is Utopia 

level 1 . In Utopia level 2 slave mode, the port will respond when this address is polled by the master. 

5 Utopia level: 0 for level 1, 1 for level 2. 

6 Utopia Master/Slave: 0 for Slave, 1 for Master. 

7 Utopia Bus Width: 0 for 8 bit, 1 for 16 bit Note: current Mako only supports 8 bit. 

^ " ^2 Utopia PHY number. This field is ignored if the Utopia is a master or is Utopia 

level 1 . In Utopia level 2 slave mode, the port will respond when this address is polled by the master. 

13 Utopia level: 0 for level 1, 1 for level 2. 

141 Utopia Master/Slave: 0 for Slave, 1 for Master. 

5 Utopia Bus Width: 0 for 8 bit. 1 for 16 bit. Note: current Mako only supports 8 bit. 

1^-20 Utopia PHY number. This field is ignored if the Utopia is a master or is Utopia 

level 1 . In Utopia level 2 slave mode, the port will respond when this address is polled by the master. 
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21 Utopia level: 0 for level 1, 1 for level 2. 

22 Utopia Master/Slave: 0 for Slave. 1 for Master. 

23 Utopia Bus Width: 0 for 8 bit, 1 for 16 bit. Note: current Mako only supports 8 bit. 

2^ " 28 Utopia PHY number. This field is ignored if the Utopia is a master or is Utopia 

level 1. In Utopia level 2 slave mode, the port will respond when this address is polled by the master. 

29 Utopia level: 0 for level 1, 1 for level 2. 

30 Utopia Master/Slave: 0 for Slave, 1 for Master. 

3 1 Utopia Bus Width: 0 for 8 bit, 1 for 16 bit. Note: current Mako only supports 8 bit. 

9. Functional Block Descriptions 

The following components and sub-systems provide the fimctionality to support the test fimctions specified 
above. 

9.1. CellPtrs 

The CellPtrs block is actually packaged inside the PointerSwitch block. It consists of threaded lists of BNs 
and routines to move them fi-om one queue to another. Empty BNs are kept in the FreeQ. BNs containing 
Cells are linked to per-Ci queues. The following figure is a generic block diagram applying to the routines in 
the CellPtrs block. 

As implied in the figure, there are multiple request, acknowledge, Clld and Ci inputs. There is one set per 
client. A calling client places its CUd and the Ci to be affected onto the Clld and Ci busses to which it is 
connected. It requests the routine's service by asserting its BfRq. When the routine has serviced the client, it 
asserts BfAk. Note that BfRq and BfAk are generic. The actual signals will be GetBfRq, RlsBfRq, etc. 
depending on which routine is being called. Outputs fi-om the CellPtrs block consist of address, data, request 
and acknowledge signals to access SRAM. 

The GetBf routine ejctracts one BN fi-om the FreeQ and places it on the Ci queue. 

The RlsBf routine extracts one BN fi-om the Ci queue and puts it back on the FreeQ. 

All of the CellPtr routines use a pair of pointer registers and two sets of SRAM based pointers. FreeQFrst 
and FreeQLast are registers which indicate the first and last BNs m the fiee queue. Upon initialization, these 
are set to the lowest and the highest numbered BN, respectively. 

9.2. TDM Interface 

This inteifeces to TDM highway that supports up to 4 Tl/El Ime inter&ce units (LIU). 

9.3. TdmRes 

The TdmRes block diagram is shown in the following figure: 
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FrmDatAvail, FrmSo^ FrmDatRdClk and FnnDatIn are signals associated with the Frame I/F. FmSegRq, 
FnnSegAk, FrmDatOut and Ci are mter€ace signak to the TdmSeg block. The signals on the right side 
provide access to SRAM. 

9.4. TdmSeg 

The TdmSeg block segments frame payloads into streams of AAL-5 encoded ATM cells with zero fill, as 
necessary, and AAL-5 trailer. While processing the frame. TdmSeg verifies the fi^e CRC. If the CRC is 
bad, the frame is discarded and the BadFrm counter is incremented. 

Each cell is assigned a BN via a caD to GetBf If no BN is available, the frame is discarded and the OvfFrm 
counter is incremented. If a BN is available, GetBf adds a BPtr to the Ci's queue, leaving the FH and 
CndSd fields zero. TdmSeg fills in the PTI field. TdmSeg then stores the cell payload data in the associated 
BPld entry. 

9.5. TdmReas 

The TdmReas (Frame Reassembly) block receives BfNm's from the PointerSwitch block. When TdmReas 
receives a BfNm, it examines the associated cell to see whether it is the last cell of a fi^e payload. If not, it 
simply leaves the new BfNm on its queue. If it is the last ceU of a fiame PDU, TdmReas extracts all the ceUs 
of the PDU from its queue and forms the outgoing firame, including encq)sulation headers. In the process, it 
releases the BfNm*s of all the associated cells back to the FreeQ. 

9.6. Cell Interface 

The Cell Interfece block is a Utopia interface, selectable to level 1 or level 2 by the UtCfg register. 

9.7. CellRes 

The CellHdrRes block examines the VPI. VCI and PTI fields of incoming cells and associates them with Ci's. 

9.8. CellXlt 

9.9. PointerSwitch 

9.10. CellSched 



10. Software Interface 

The ARM microprocessor interfeces vwth Mako over a Local Bus. The Local Bus interlace runs at 33 MHz 
and connects the ARM CPU to various peripherals, inchiding the Mako. The Local Bus interface is used to 
pass management and control information to and fi-om the ARM to the various communication ports as well 
as providing configuration, control and status repsters and access to the Mako RAM tables. The re^sters 
are memory mapped to the ARM memory address space. 
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Scheduler High Level Information 

- Sch.vhd 

- This is the module that applies quality of service to cell streams. 

- It is part of Mako versions 0x30000002 and above. 

- There may be many ports with widely different line rates. In order 

- to assure that each port is serviced with a relative frequency 

- conmiensurate with its relative rate, the host CPU builds a_Eort 
-jSEv ice sequence table, PtSq.J n DRAM. It is a sequence of port 

- numbers, with port numbers of fast ports occuring more frequently 

- than port numbers of slow ports. The Pq state machine reads the 

- PtSq and queues up a service list in the PtSq FIFO 

- Incoming QSw requests in the Sqt are'qualified by the^q^state machine. 

- For thoSe-that qualify, i.e.'whose' Ci's are not already active or are 

- CT/QFC blocked, their Ci's are put into a CiAq FIFO for activation. 

- Ci Activation and cell queing and are performed by the Sch state machine. 

- It alternates between activating Ci's and queing cells. 

- Cell queing is actually cell sequencing. The scheduler determines 

- the sequence in which a mix of data and idle cells is sent. 

- Scheduling is performed by the output port logic at the port line 

- rate. Each Ci is given priority and allocated a ratio of of transmit 

- opportunities based on its assigned QoS and programmed rate. 

- The core element of the scheduler is the Bubble Table that contains 

- timed and prioritized set of cell transmit requests for one port at 

- a time. It is actually a group of sub tables. Each sub table contains 

- requests for one QoS within the port. The first priority decision 

- is between QoS's and tiie second is between Ci's based on next target 

- time and programnied rate. 

- The highest priority cell is queued for sending by placing it's Bn 

- in CiPtr(Ci)->Sch. The sequence of queued cells begins with the 

- Bn in CiPtr(Ci)->Out and chains through BPtr(Bn) until reaching 

- the last scheduled cell's Bn in CiPti-(Ci)->Sch. After a cell is 

- queued up, the next target time is calculated by adding the interval 

- time for the Ci to the previous target time. Target time and 

- Interval time are formatted as fixed point fractions, thus allowing 

- effective line rates to be specified with fine granularity. 

- After the next target time is calculated, a binary search is made 

- witiiin the QoS sub table based on target time and Ci rate, ff 

- multiple Ci's in the same QoS have the same target time, they are 

- prioritized by rate; faster rate results in higher priority. 
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— After the comparison search, if the Ci entry is no longer the highest 

— priority, it will be removed from the Bubble Table by shifting all 

— Bubble Table entries above it down by one. If the Ci is to remain 

— enabled, a new place for the Ci entry will be created by shifting 

— the entry in the new place and all entries above it up by one place. 
~ The Bubble Table architecture is such that this shifting process 

~ is very fast. A small number of clock cycles (as few as one) to 

— prepare and one clock cycle to execute the shift. 

— Ci's are activated or deactivated dynamically based on cell 

~ availibility and QoS criteria. If there are no cells in the CiPtr(Ci) 
~ queue, the Ci will be disabled. If there are cells in the queue 

— criteria to enable the Ci depend on QoS in priority order as follows: 

— Pacing CBR: 

~ Ci enabled anytime any data Ci is enabled on the port. These virtual 

— streams generate idle cells on the port to throttle data when the 

~ port has an artificially reduced line speed. Multiple Pacing CBR Ci's 

— are allowed to achieve fine granularity in reduced line rate. 

— CBR: 

~ Ci always enabled. This QoS will not be overbooked by software. 
" VBRrtorVBRnrt: 

— Ci Enabled unless it has filled its limit for cells within a measure. 

— A measure is a count of transmit opportunities representing about 
~ 125 msec. This count will vary according to the line rate of the 

— of the port. The SCR of this QoS will not be overbooked. 

— VBRrtorVBRnrt: 

~ Ci Enabled unless it has filled its limit for cells within a measure. 
ABR 

~ Ci is always enabled. ABR is like CBR except that it is lower 

— priority and the effective PCR can change dynamically. 

" QFC/CT 

— Ci is enabled until the Tx credit limit is reached. Once disabled 
~ because of credit limit, it can be reenabled by an incoming credit 

— update cell. 

— UBR 

— Ci always enabled. UBR is treated like CBR except that it is the 

— lowest priority. UBR is actually UBR++ since it always has a PCR. 

— It is equivalent to UBR if the PCR is programmed at line rate. 
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ThVBRrt 

Ci always enabled. VBRrt Ci's are moved to this QoS when their limit 
of cells per measure is reached. 

ThVBRnrt 

Ci always enabled. VBRnrt Ci's are moved to this QoS when their limit 
of cells per measure is reached. 

Several tables and registers are used by the scheduler. Some are stored 
in DRAM, others in SRAM. 

There are three imbedded SRAM blocks. 

PtSq block: 8 bits wide x 256 deep. Each byte is seen by the host 
CPU as the significant 8 bits of a Dword. These dwords 
occupy 0x400000 - Ox4000FF in Mako Ram address space. 

SchPt block: 106 bits wide x 64 deep. Only the least significant 
26 bits of each entry is visible in Mako Ram address 
space. These are at addresses 0x400100 - 0x400 13F. 

SchBt block: 1440 wide x 64 deep. These are not visible in Mako Ram 
address space. 

The following tables are used: 

Switch Request Related: 

SqT (Switch request Queue Table) 

SqT contains one entry per port. 

- Each entry in SqT contains the following fields: 

SqT(SwClt)->In (wd 0 bits 0 - 15) = number of newest Sr 
SqT(S wClt)->Out (wd 0 bits 1 6 - 3 1 ) = number of oldest Sr 
SqT(SwClt)->In (wd 1 bits 0 - 15) = number of Sr's pending for port 

- SrT (Switch Request Table) in DRAM 

SrT contains one entry per Switch Request Buffer 
Each SrT entry contains the following fields: 



Scheduler High Level Infonnatioi. 

SrT(Sm)->Nxt (bits 0 - 15) = Next Switch Request* in chain 
SrT(Sm)->Ci (bits 16 - 24) = Ci of the cell being switched 
SrT(Sm)->unused (bits 25 - 31) = unused 

Cell Buffer related 

CiPtr (Ci Pointers) in DRAM 

CiPtr points to cells threaded on per Ci queues. 

Each CiPtr entry contains the following fields: 

CiPtr(Ci)->In (bits 0 - 15 of 1st word) = Bn of newest cell 
CiPtr(Ci)->Out (bits 16 - 31 of 1st word) = Bn of oldest cell 
CiPtr(Ci)->Ocp (bits 0 - 15 of 2nd word) = Bn's occupied by this Ci 
CiPtr(Ci)->Sch (Ijits 16 - 3 1 of 2nd word) = Last Bn processed by Sched 



Bptr (Buffer Pointers) in DRAM 

BPtr contains chaining pointers for Bn's that are on the various 
buffer queues. 

Each BPtr entry contains the following field: 

BPtr(Bn)->Nxt (bits 0 - 15) = Next Bn in chain 
BPtr(Bn)->unused (bits 16 - 31) = unused 



BPld (Buffer Payloads) in DRAM 
~ BPld contains the headers and payloads of the cells on the various queues 

- Each BPld entry contains the following field: 

BPld(Bn)->Hdr (1st word) = Cell Header 
BPld(Bn)->Pld (2nd - 1 3th word) = Cell payload 

- Scheduler Port Sequencing related: 

- PtSq (Port Sequence Table) in Sram 

Software calculates the sequence in which ports need to be serviced and 

- builds the sequenced list of port buffer numbers into the PtSq. Entries 

- are 1 byte each. The first byte in the table contains die total number 
of entries, which begin with the second byte of the table. 



4 



Scheduler ffigh Level Informatio. 



« PtSqWd (Port Sequence Word Number) register 

- PtSqWd contains the current PtSq word number. When the value is 0 

- the first word of PtSqWd is fetched, refreshing knowledge of the 
" number of entries in the table since lower 10 bits of the first word 

- contain the total number of entries in the table. 

- PtSqOfst 

- PtSqOfst is the offset of the current port sequence number within the 

- currently cached 3 1 bit word. 0 = first (need to read), 1 = 2nd, 2 = 3rd. 

- PtSqMax 

- PtSqMax holds the total number of port numbers in the PtSq. 

- Active Port Related: 

- PtSq (Port Scheduler Queue) fifo 

- This is a fifo of port numbers that are active and need to be scheduled. 
" SchPtBf 

- This register contains the current port number buffer associated with 
the scheduler. 

- SchPt, SchPtRg (Scheduler per-Port Table) in SRAM and registers 

- The SchPt Table contains an entry per Port. Up to 64 entries are 

- in SRAM. The active entry is in SchPtRg which corresponds to SRAM 
buffer number PtBfNum. SchPt(PtBfNum)->Pt tells the Pt. Host 

- software allocates the PtBfNum's to the ports and initializes it by 

- zeroing the entire table, then writing port numbers into the 

- SchPt(PtBfNum)->Pt fields. It is stored as one wide parallel 

~ word in SRAM but is accessible to the host CPU through the DRAM 

- registers as though it were stored as contiguous little endian 

- 32 bit words. 

- SchPt(PtBfNum)->PcbrCnt (bits 105 downto 104) = Number of Pacing Constant 
Bit Rate Ci's (max=4) 

- SchPt(PtBfNum)->CbrCnt (bits 103 downto 98) = Number of Active Constant 
Bit Rate Ci's 

SchPt(PtBfNum)->VbrrtCnt (bits 97 downto 92) = Number of Active Variable 
Bit Rate real time Ci*s 
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- SchPt(PtBfNum)->VbmrtCnt (bits 91 downto 86) = Number of Active Variable 
Bit Rate not real time Ci's 

- SchPt(PtBfNum)->AbrCnt (bits 85 downto 80) = Number of Active Available 
Bit Rate Ci's 

-- SchPt(PtBfNum)->QfcCnt (bits 79 downto 74) = Number of Active QFC Ci's 

- SchPt(PtBfNum)->UbrCnt (bits 73 downto 68) = Number of Active UBR Ci's 
-- SchPt(PtBfNum)->UbPlsrCnt (bits 67 downto 62) = Number of Active UBR Ci's 

- SchPt(PtBfNum)->ThVbrrtCnt (bits 61 downto 56) = Number of Active Throttled 
VBRrt Ci's 

-- SchPt(PtBfNum)->ThVbmrtCnt (bits 55 downto 50) = Number of Active ThrotUed 
VBRnrt Ci's 

- SchPt(PtBfNum)->ThUbrPlsCnt (bits 49 downto 44) = Number of Active ThrotUed 
VBRnrt Ci's 

- SchPt(PtBfNum)->MsrCnt (bits 43 downto 28) = Current PIC counts in the 
measure 

- SchPt(PtBfNum)->Pic (bits 27 downto 14) = Port Interval Counter 

- SchPt(PtBfNum)->MsrPwr2 (bits 13 downto 10) = Log2 of max counts in a 
measure 

- SchPt(PtBfNum)->Pt (bit 9 downto 0) = Port number 

- Active Ci Related: 

- CiAq (Ci Activation Queue) fifo 

- This is a fifo of Ci numbers that need to be activated. 

- CiStat, CiStatRg (Ci Status) in Dram, 16 Ci's per 32 bit word. 
~ This table is located at offset 0x8000 above the start of SchCi. 

- CiStat(Ci)->Act (bit 0) = Ci active 

- CiStat(Ci)->QfcBlkd (bit 1) = Ci is QFC & out of Xmt credits 

- CiStatNum (Ci Status Number) register 

- Bits 4 and up of Ci numbers cached in CiStatRg 

- SchCi (Scheduler per-Ci Table) in Dram, cached in a register. 
~ This table is located at the address pointed to by PLSchBase. 

~ Each entiy consists of 4 dwords.There is an entry for each Ci. 

~ Ci 0 is reserved. Ci 1 through 8 19 1 are the available assignable 

~ Ci's. Ci's above 8 192 are reserved for PCBR Ci's. There are 4 

~ such enti-ies for each port. In the PCBR Bt entry the Ci number 

" shall be in the range 0-3. The overall Ci number is equal to 

- 8 191 + 4*Port Number + Bt Ci number. Thus Ci numbers for PCBR 
are pre-allocated. 
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~ The first dword has the same function for all QoS's. 

~ Subsequent words depend on QoS with the exception that bit 3 1 

~ of the 4th word is the trottled stahis bit. The 1st word is 

~ only written by the host PC. The 4th word is only written by 

~ Mako. The writer of words 2 and 3 depends on the QoS. 

- SchCi(Ci)->Thrfld (Wd 0 bit 31) = When set it means that this Ci is throttled 
-- SchCi(Ci)->Unused (Wd 0 bits 30 downto 28) 

SchCi(Ci)->FrctTm (Wd 2 bits 27 downto 25) = Fractional portion of TgtTm 

- SchCi(Ci)->CiPtBf (Wd 0 bits 24 downto 18) = SRAM buffer number of the 
destination port for the Ci 

-- SchCi(Ci)->ItInt (Wd 0 bits 17 downto 6) = 12 bit integer portion of Interval Time 
-- SchCi(Ci)->ItFrct (Wd Obits 5 downto 3) = 3 bit fractional portion or Interval 
Time 

-- SchCi(Ci)->QoS (Wd Obits 2 downto 0) = Quality of Service for Ci, 0=PCBR, 
1=CBR, 2=VBRrt, 3=VBRnrt, 

4=ABR. 5=QFC, 6=UBR+ & 7=UBR 

for PCBR, CBR and UBR 

- SchCi(Ci)->Unused (Wd 1 bits 31 downto 0) 

- SchCi(Ci)->Unused (Wd 2 bits 3 1 downto 0) 

- SchCi(Ci)->Unused (Wd 3 bits 3 1 downto 0) 

- for VBRrt and VBRnrt 
-- SchCi(Ci)->MsrCnt (Wd 1 bits 31 downto 16) 
this Time Measure Unit 

- SchCi(Ci)->MsrMax (Wd 1 bits 15 downto 0) 
Measure before throttling 

-- SchCi(Ci)->Unused (Wd 3 bits 31 downto 16) 
SchCi(Ci)->MsrRoll (Wd 2 bits 15 downto 0) : 
Unit that sent count represents 

-- forABR 

-- SchCi(Ci)Wd 1,2,3 TBD 

- forQFOCT 

- SchCi(Pt)->RxCnt (Wd 1 bits 31 downto 24) = Rx count 

- SchCi(Pt)->TxCnt (Wd 1 bits 23 downto 16) = Tx count 
-- SchCi(Pt)->RxQtm (Wd 1 bits 15 downto 8) = Rx Quantum 

- SchCi(Pt)->TxLmt (Wd 1 bits 7 downto 0) =Tx limit 

- SchCi(Ci)->Unused (Wd 2 bits 31 downto 0) 
-- SchCi(Ci)->Unused (Wd 3 bits 31 downto 0) 
~ Note: SchCi(O) contains QFC info for the port 

- SchCiNum (Ci Number register) 



= The number of cells sent during 
= Max cells to be sent in a Time 

= Rollover count of Time Measure 
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Scheduler High Level Information 



— This internal register has the number of the Ci whose SchCi entry is loaded in the 
SchCi register. 

— SchCiNum->(bits 13 downto 0)= The Ci represented by the loaded SchCi 

— Cell Scheduling Time Related: 

" Bt (Bubble Table) in SRAM and registers 

— Each SchBt entry is a request to queue a cell for transmit on a Ci 

— at a target time. There is an ordered group of entries per QoS. 

— There is an ordered set of QoS groups per port. In other words, 

~ the SchBt contains three hierarchies of ordering: by port; by Qos; 

— by cell target time. 

— The SchBt is physically partitioned into pages of 32 entries each. 

— 64 pages are cached in SRAM. The active page is cached and 
processed in registers. 

— Each SchBt entry contains the following fields: 

— SchBt->TtInt (bits 44 downto 31) = Integer portion of Target Time 

— SchBt->TtFrct (bits 30 downto 28) = Fractional portion of Target Time 
SchBt->IvInt (bits 27 downto 16) = Integer portion of Interval Time 

— SchBt->IvFrct (bits 15 downto 13) = Fractional portion of Interval Time 

— SchBt->Ci (bits 12 downto 0) = Ci 

The SchBt is initialized to all zero. Segments of the page in 
registers can be shifted up and down for insertion and deletion 

— of entries. The most significant bit of all the SchBt->Tf[nt fields 
in the register can be concurrently zeroed in one clock cycle. 

— PUC (Port Useage Count) 64 Sram entries of 16 bits 

— These counters contain the count of MIC when this port last sent a cell. When the 
MIC overflows, 

— the MIC is reset to 0x0100 and the upper 8 bits of each PUC is shifted to the lower 
8, with the upper 

— being set to 0. 

— PUC(entry)->Mic (bits 15 downto 0) =MIC value when last cell sent for Port 

~ FuUMic (Full Master Interval Counter) 
(64 bit register, 2 double words) 
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Scheduler High Level Mormatioit 

- This complete counter will record the number of cells transmitted, less 256 for ev 
65.536 

~ because when the lower 16 bits overflow they are reset to 0x0100 instead of zero. 
This is 

~ to retain proper ordering on the PUC's. 

~ FullMic->MicOfl (bits 63 downto 16) = Overflow count of MIC 

- FullMic->Mic (bits 15 downto 0) = Value placed in PUC 

~ This 10 bit register keeps count of the number of active ports at the moment. 

- NumActPt->(bits 9 downto 0) 

- CqSt qualifies cells for scheduling and puts qualified cells in Ci 
-- activation queue. 

~ CqStOO 

-- if((CiAqFull) or (not SwAlert and not (CiAqPullDlyd and not CiAqFuU))) 

- goto CqStOO ^ 

- CqStOl 

- if(CqCi <= Sqt(0)->Out = 0) - Using CqCi to hold Sr temporarily 

- goto CqStOO 

- CqSt02 

- RlsSr(O) 

- CqSt03 

- if(CqCi <= Srt(CqCi)->Ci = 0) 
-- goto CqStOl 

-- CqSt04 

- if(CqCi bits 4 and above = CiStatNum) 
~ goto CqSt06 

- assert RamMore 

-- CiStat(CiStatNum) <= CiStatRg 

- CiStatNum <= CqCi»4 

- CqSt05 

- CiStatRg <= CiStat(CiStatNum) 

- CqSt06 

if(CiStatRg(CqCi(3:0))->Act /= 0 or CiStat(CqCi(3:0))->Qfc /= 0) 
-- goto CqStOO 

- add CqCi to CiAq fifo 
~ CiStat(CqCi)->Act <= 1 
-- goto CqStOO 

- SchSt activiates Ci's into the Bubble Table and schedules Ci's on a per 

- port basis. 

- Static 
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Offsets in BTbl of the Qos groups 
BtPcbr <= 0 

BtCbr <= BtPcbr + SchPtRg->PcbrCnt 
BtVbrrt <=BtCbr + SchPtRg->CbrCnt 
BtVbmrt <= BtVbrrt + SchPtRg->VbrrtCnt 
BtAbr <= BtVbmrt + SchPtRg->VbnirtCnt 
BtQfc <= BtAbr + SchPtRg->AbrCnt 
BtUBRPls <= BtQfc + SchPtRg->QfcCnt 
BtUbr <=BtUbrPls + SchPtRg->UbrPlsCnt 
BtThVbrrt <= BtUbr + SchPtRg->UbrCnt 
BtThVbmrt<= BtThVbrrt + SchPtRg->ThVbrrtCnt 
BtThUbrPls<= BtThVbmrt+ SchPtRg->ThVbmrtCnt 
PtAct <= BtTot /= SchPtRg->PcbrCnt 

BtQos(QoS)<= Mux selected by QoS with BtPcbr, et al as inputs 
if(SchCi->QoS = Pcbr) 
BtStrt <= BtPcbr 
BtCnt <= SchPtRg->PcbrCnt 
if(SchCi->QoS = Vbrrt) 
BtStrt <= BtVbrrt 
BtCnt <= SchPtRg->VbrrtCnt 
if(SchCi->QoS = Vbmrt) 
BtStrt <= BtVbmrt 
BtCnt <= SchPtRg->VbmrtCnt 
if(SchCi->QoS = Abr) 
BtStrt <= BtAbr 
BtCnt <= SchPtRg->AbrCnt 
if(SchCi->QoS = fc) 
BtStrt <= Btfc 
BtCnt <= SchPtRg->fcCnt 
if(SchCi->QoS = UbrPls) 
BtStrt <= BtUbrPls 
BtCnt <= SchPtRg->UbrPlsCnt 
if(SchCi->QoS = Ubr) 
BtStrt <= BtUbr 
BtCnt <= SchPtRg->UbrCnt 
TgtTm <= SchCi->ItInt&SchCi->ItFrct + SchPt->Pic&SchCi(Ci)->FrctTm 
SchStOO 
PoUQos <= 0 

SchCqTm <= not CiSrvTm 

if((SchCqTm and CiAqEmpty) or (not SchCqTm and SchPtBf = 0)) 
goto SchStOO 
if(not SchCqTm) 
goto SchStOB 

* * « * * « * 4c * * * « * 4^ 

* Activate a Ci * 
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- if(SchCiNum = 0) 

- WdCnt <= 0 
-- goto SchSt02 

- if(SchCiNum = CiAq or SchCi(Ci)-VQoS = (PCbr or Cbr or Abr or Ubr)) 

- WdCnt <= 0 ' 

- goto SchSt03 
~ WdCnt <= 2 

~ SchStOl ~ save volatile part of old SchCi entry 

~ SchCiBase(4*SchCiNum + WdCnt) <= SchCiRg(WdCnt) 

- if(WdCnt/=2) 

- WdCnt-H- 

- goto SchStOl 
~ WdCnt <= 0 

~ SchSt02 — retrieve new SchCi entry 

- SchCiRg(WdCnt) <= SchCiBase(4*CiAq + WdCnt) 

- WdCnt-H- 

- if ((new SchCiRg->QoS = (Vbrrt or Vbmrt or Qfc) and WdCnt /= I) or (new 
SchCiRg->QoS = Abr and WdCnt /= 2)) 

- goto SchSt02 

- SchStOS 

- SchCiNum<= CiAq 
~ pop CiAq 

~ if(SchPtBf = SchCiRg->CiPtBf) 

- goto SchStOT 
-SchSt04 

-- SchPt(SchPtBf) <= SchPtRg - save current SchPt 

- SchBt(SchPtBO <= SchBtRg ~ save current SchBt 

- SchPtBf <= SchCiRg->CiPtBf 

- SchStOS 

- SchPtRg <= SchPt(SchPtBf) - retrieve new SchPt 
-- SchBtRg <= SchBt(SchPtBf) -- retrieve new SchBt 
-- SchSt06 

- if(TgtTm msb = 0 and SchPt->Pic msb = 1) 

- zero msb of all SchBt->TgtInt's 
~ zero msb of SchPt->Pic 

-- SchStO? 

-- BtNdx <= SchSrch(TgtTm,BtQos(SchCi->Qos),BtCnt(SchCi->Qos)) 

- BTbl(ShClr) - clear Bt shift enables 

- SchStOS 

~ BTbl(ShLdRq,BtNdx) & wait for BTbl(ShLdAk) - set shift starting point 

- BTbl(ShUp) 

- SchSt09 

- SchBtRg(BtNdx)->TtInt&->TtFrct <= TgtTm 

- SchBtRg(BtNdx)->ItInt&->ItFrct <= SchCi->ItInt&SchCi->ItFrct 

- SchBtRg(BtNdx)->Ci <= SchCiNum 

- SchStOA 
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- if(SchCi->Qos = Cbr) 

- SchPtRg->CbrAct <= 1 

- SchPtRg->CbrCnt-H- 

- if(SchCi->Qos = Vbrrt) 

- SchPtRg->VbrrtAct <= 1 

- SchPtRg->VbrrtCnt++ 

- if(SchCi->Qos = Vbmrt) 

- SchPtRg->VbmrtAct <= 1 

- SchPtRg->VbmrtCnt-H- 

- if(SchCi->Qos = Abr) 

- SchPtRg->AbrAct <= 1 

- SchPtRg->AbrCnt-H- 

- if(SchCi->Qos = Qfc) 

- SchPtRg->QfcAct <= 1 

- SchPtRg->QfcCnt++ 

- if(SchCi->Qos = Ubr) 

- SchPaig->UbrAct <= 1 

- SchPtRg->UbrCnt-H- 

- gotoSchStOO 

- * Service a port * 

- SchStOB 

- NewPtBf <=PtSq(NxtPt) 

- NxtPt++ ~ but not until after this state 

- if(PtSq(NxtPt) = SchPtBf) 

- goto SchStOF 

- SchStOC 

-- SchPt(SchPtBf) <= SchPtRg - save current SchPt 
-- SchBt(SchPtBf) <= SchBtRg - save current SchBt 
-- SchPtBf <= NewPtBf 

- SchStOD 

- SchPtRg <= SchPt(SchPtBf) - retrieve new SchPt 

- SchBtRg <= SchBt(SchPtBf) - retrieve new SchBt 

- SchStOE 

- if(notPtAct) 

- goto SchStOO ~ done cuz no active Ci's 

- SchPtRg->Pic++ 

-- if(Qos = Vbrrt or Qos = Vbmrt or Qos = UbrPls) 
-- SchPtRg->MsrCnt++ 

-- if(bit SchPtRg->MsrPwr2 of SchPtRg->MsrCnt doesn't go from 1 to 0) 
goto SchStl? ~ jmp if not at end of measure 

- if(SchPtRg->Th VbrrtCnt = 0 and SchPtRg->ThVbmrtCnt = 0 and SchPtRg- 
>ThUbrPlsCnt = 0) 

~ goto SchStl? - jmp if nothing to unthrottle 
-- if(SchPtRg->ThVbrrtCnt = 0) 
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- goto SchStl3 ~ jrap if no VBRrt to unthrottle 

- * Unthrottle at end of measure * 

- SchStOF 

- BtNdx <= SchSrch(SchBtRg(BtQos(ThVbrrt))->TtInt&->IvInt&- 
>IvFrct3tQos(Vbrrt)) 

~ BTbl(ShClr) - clear Bt shift enables 

- SchStlO 

- BTbl(ShLdRq,BtNdx) & wait for BTbl(ShLdAk) -- set shift starting point 

- BTbl(ShUp) 
-SchStU 

- SchBtRg(BtNdx) <= SchBt(BtQos(ThVbrrt)) 

- SchStl2 

- BTbl(ShLdRq,BtQos(ThVbrrt)) & wait for BTbl(ShLdAk) - set shift starting point 
~ BTbl(ShDn) 

- if(SchPtRg->ThVbrrtCnt /= 0) 

- goto SchStl2 

- if(SchPtRg->ThVbmrtCnt /= 0) 
~ goto SchStl? 

- SchStlS 

-- BtNdx <= SchSrch(SchBtRg(BtQos(ThVbrrt))->TtInt&->IvInt&- 
>IvFrct,BtQos(Vbnt)) 

- BTbl(ShClr) - clear Bt shift enables 

- SchStM 

- BTbl(ShLdRq,BtNdx) & wait for BTbl(ShLdAk) - set shift starting point 

- BTbl(ShUp) 
-SchStlS 

- SchBtRg(BtNdx) <= SchBt(BtQos(ThVbrrt)) 

- SchStl6 

- BTbl(ShLdRq,BtQos(ThVbrrt)) & wait for BTbl(ShLdAk) -- set shift starting point 

- BTbl(ShDn) 

- if(SchPtRg->ThVbrrtCnt /= 0) 

- goto SchStl6 

- * Check for ready Ci * 

- SchStl? 

- if(SchBt(BtQos(PollQos))->TtInt> SchPt->Pic) 

- if(PollQos = Ubr) 

- goto SchSt25 ~ go send idle cell cuz no Ci ready 

- PoUQos-H- 

~ goto SchStl? 

- SchBtRg(BtQos(QoS))->TtInt&->TtFrct <= TgtTm 

- if(PollQos = Pcbr) 

goto SchSt25 ~ go send idle cell cuz Pcbr ready 
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- * Send data cell * 

"SchStlS 

- assert RamMore 

~ SchNxtBn <= CiPtr(SchBt(BtQos(QoS))->Ci)->Out 
-- SchLstBn <= CiPtr(SchBt(BtQos(QoS))->Ci)->In 
-- SchStl9 

- assert RamMore 

- SchOcp <= CiPtr(SchBt(BtQos(QoS))->Ci)->Ocp 
-- if(CiPtr(SchBt(BtQoS(QoS))->Ci)->Sch = 0) 

- goto SchStlB 
-- SchStl A 

~ assert RamMore 

- SchNxtBn <= BPtr(SchBn) 
-- SchStlB 

- CiPtr(SchBt(BtQos(QoS))->Ci)->Ocp <= SchOcp 
CiPtr(SchBt(BtQos(QoS))->Ci)->Sch <= SchNxtBn 

-- SchStl C 

- GetSr(SchBt(BtQos(QoS))->Ci) 

- if(SchNxtBn /= SchLstBn) 

-- goto SchSt21 
__ /***************\ 

- * Deactivate Ci * 
-- SchStlD 

-- if(SchBt(BtQoS(QoS))->Ci bits 4 and above = CiStatNum) 

- goto SchStlF 
~ assert RamMore 

- CiStat(CiStatNum) <= CiStatRg 

- CiStatNum <= SchBt(BtQoS(QoS))->Ci»4 
-- SchStlE 

-- CiStatRg <= CiStat(CiStatNum) 
-- SchStlF 

- CiStatRg(SchBt(BtQoS(QoS))->Ci(3 :0))->Act <= 0 

- BTbl(ShClr) -- clear Bt shift enables 

- SchSt20 

- BTbl(ShLdRq,BtQoS(QoS)) & wait for BTbl(ShLdAk) - set shift starting point 

- BTbl(ShDn) 

- SchBtRg->QoSCnt- 

- gotoSchStOO 

- * Update Bubble Table * 
-- SchSt21 

-- BTbl(ShClr) -- clear Bt shift enables 
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- if(SchBtRg->QoSCnt = 1) 
-- goto SchStOO 

- BtNdx <= SchSrch(SchBtRg(BtQos(QoS)+l)->TtInt&->IvInt&- 
>IvFrct,BtQos(Vbrrt)) 

- if(BtNdx = BtQoS(QoS) 

- goto SchStOO 
~ SchSt22 

- BTbl(ShLdRq,BtNdx) & wait for BTbl(ShLdAk) - set shift starting point 

- BTbl(ShUp) 

- SchSt23 

- BTbl(ShCh-) - clear Bt shift enables 

- SchSt24 

-- BTbl(ShLdRq,BtQos(QoS)) & wait for BTbl(ShLdAk) - set shift starting point 
-- BTbl(ShDn) 
-- goto SchStOO 

- * Send idle cell * 

- SchSt25 

- Assert Swidle 

- GetSr(SchPtRg->Pt) 

- if(PollQoS = Pcbr) 
-- goto SchSt21 

-- goto SchStOO 
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A Single Scheduler to Fully Service Multiple Qualities of Service 



Description of Related Arts 

Traditional ATM cell schedulers and QoS oriented packet schedulers implement separate logic blocks for 
each Quality of Service (QoS). These logic blocks output their cell/packet streams to individual queues 
or FIFO's which are then drained by another logic block prioritizing between the queues. 

With this approach, there is considerable duplication of logic since the service for any QoS contains 
much core functionality common to the service of any other QoS. The existence of multiple separately 
managed queues or FIFO's also requires large amounts of storage, either in the form of register bits or 
RAM cells. Highly intelligent queue management can increase storage efficiency but adds complexity. 

Figure 43 is a block diagram showing a prior art scheduler for multiple qualities of service. 

Summary of the Invention 

A limited set of functions is necessary to support the basic QoS*s required and recommended in cun-ent 
standards issued by bodies such as the ITU-T, ATM Forum and IETF. A single scheduler can be 
implemented with algorithms to perform these basic functions and with access to control parameters 
allowing easy adaptation to future QoS's and Flow Control mechanisms. 

Figure 44 is a block diagram showing a single scheduler to fully service multiple qualities of 
service according to the present invention. 

The invention reduces complexity by providing a common core that performs the micro-scheduling 
operations and decisions to support constant, variable and unspecified bit rate services plus providing 
easily accessible primitives facilitating extension to future high level QoS, flow control and policy based 
flow management functions. 

Detailed Description of the invention 

The invention places into a single scheduler the basic functionality to support multiple QoS's. A few key 
architectural considerations contribute to this capability. 

1 . A key is created for each flow containing the following information: QoS number in which the higher 
the QoS priority the lower the number; desired time, measured in transmit opportunities, for the next 
transmit; Interval time desired between transmits; flow number. Instantaneous transmit priority 
decisions among incoming flows are made based on the ordered set of these keys plus a partial 
index that identifies changes in QoS number. 

2. QoS's may be assigned more than one number and the facility is provided to switch between the 
numbers dynamically in order to accommodate conditional changes in priority of the stream as 
window sizes or the guaranteed portion of its bandwidth in a time interval are met It is important to 
note that the flow is not switched to a different queue but that the instantaneous priority of the data 
stream is changed. Thus there is no possibility of cell/packet order corruption as would be the case 
in a traditional queue/FIFO oriented implementation. 
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QoS numbers sufficiently large disable transmission to accommodate QoS's which require a 
temporary stoppage of cell/packet forwarding. 

An interface is provided for external processes to dynamically change QoS number or Interval time to 
allow wide flexibility and expandability relative to high level QoS and policy management algorithms 
and logic. 
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Algorithm to Assign Scheduler Resource to Multiple Ports in Correct 

Proportions 



Description of Related Arts 

The dynamic variation of port speed in high bandwdth switches is a relatively new phenomenon. Analog 
modems have long had the feature of connecting at different bit rates, some of them even chang^lg bit rates 
during a session. However, they operate over a standard 64 Kb voice channel through the network, simply 
chang^g their modulation scheme in adaptation to the signal to noise ratio they encoimter in a given 
connectiom Thus, even these variable bit rate sessions do not present the need, nor drive inventions to 
accommodate switching dynamic port rates. 

The recent proliferation of ATM Bandwidth on Demand and Rate Adaptive DSL have iiyected a new 
characteristic into high speed switching, i.e. hi^ speed ports whose line rates change dynamically. 

The scheduling of cells/packets to an output port requires some amount of scheduler time for each 
cell/packet. The scheduling process bandwidth inherently becomes a critical resource. Every switch 
implementation faces the problem of managjing this resource. Where throughput performance is the most 
crudal requirement, a dedicated scheduler is provided for each port so each port has immediate access to 
scheduling resource. However, when economics is important, scheduling resources are shared among 
multiple ports. 

It becomes complicated when the scheduling resource is shared across ports \wth different line rates. It 
becomes particularly complicated when the ports that are sharing the resource have dynamically chan^g 
bandwidth needs. 

Traditional algorithms for sharing the scheduler resource vary from simple roimd robin port service to 
weighted service based on an ordered list of port numbers. Round robin service works well when ports are 
approximately equal in line rate. Weighted priority works well when the port line rates are constant. Neither 
of these traditional solutions works well when port line rates vary dynamically. In this case, the 
implementation must suffer the expense of multiple schedulers or suffer performance degradation. 

Summary of the Invention 

This invention applies an algorithm to determine port service order which is similar to those used in QoS 
scheduling of cells/packets within a port. Depending on performance and cost requirements, the algorithm 
may be implemented in hardware or software. 

The decision process to determine port sequendng order is equivalent to that used in determining vMch 
cell/packet to send next among the many flows of different rates pas^g through a single port. However, the 
frequency at which port sequencing decisions need to be made is typically two or three orders of magnitude 
less than the frequency that per-fiow dedsions need to be made. Thus it will usually be practical to perform 
port sequencing decisions in software or by allocating a very small percentage of hardware capacity fix)m the 
existing cell/packet scheduler. 

The result is efiBcient allocation of switching resources across ports even in the presence of dynamic port 
bandwidth changes with litde or no added cost. 
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Detailed Description of the Invention 



A cell/packet scheduler is sequentially dedicated to individual ports. For each port, it deddes which floVs 
cell/packet will be transmitted next on the port. Ports with higher line rates need to have the scheduler's 
service more frequently than ports with lower line rates. This invention addresses the algorithm for deciding 
the sequence in \s^ch ports are serviced by the cell/packet scheduler to assure that each port receives the 
proportion and frequency of service commensurate with it's line rate. 

For readability the term "cell" will be used in the remainder of this document instead of "cell/packet" but it 
will be understood that the algorithm applies to either cells or packets. 

The invention involves a stadc of entries, each of which contains a port number and a key based on pseudo 
time. The stack is ordered so that the next port to be serviced is at the front. After the port in the front entry 
is serviced, the pseudo time key is updated and the entry is reinserted into the stack appropriately to queue 
up its next service commensurate with its line rate. Any change in a port's line rate will automatically be 
taken into account the next time the port is serviced. 

The concept of pseudo time is used to provide a relative numeric indicator of temporal need for service. Rate 
is also measured in normalized units. A sorted stack of pseudo times and port nvunbers is used to choose the 
next port to service. 

A table, indexed by port number, is kept separately. Each entry in the table contains an interval count that 
correlates to the line rate of the port. 

A range of numbers is needed in which to meaningfully represent relative line rates and service times. The 
top of this range is defined by adding the cells/packets per second for all ports at their maximum line rates 
and then multiplying this my a number suflBciently large to expand it by an order of magnitude, for example 
by 10 or 16. This increased nimiber provides good granularity in representing relative rates and intervals. 

By way of example, consider a system with N ports. The sum of the maximum cells per second of all the 
ports is calculated. This sum is mxdtiplied by 10. For convenience in calculations, the result is rounded up to 
an even power of 2 and is stored in ihe variable named "Range". 

The system is initialized as follows: 

Each port is assigned a port number, "PortNura". 

Each port has an initial line rate, "PtRate(PortNum)" in cells per second. 

An array of per port service intervals, " Intvl (PortNum)" is initialized for all ports according to the initial 
line rates of the ports: 

Intvl (PortNum) = Range/PtRate(PortNum). 

A service request stack entry, "SrvRq", is constructed for each port. SrvRq has three fields. " SrvRq- 
>RqTime" contains the psoido time count identifying when the port would like to be serviced next. "Stk- 
>Intvr contains the desired service interval. "SrvRq->Port" contains the port number asociated with the 
stack entry. These fields are initialized to the following values: 



SrvRq->RqTime = 0 
SrvRq->Intvl = Intvl(PortNum) 
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SrvRq->Port = PortNum 

The service request stack entries are ordered on the stack by the key consisting of the first two fields with 
SrvRq.>Rqrime being most significant and SrvRq->Int>d being least significant. The entry with the lowest 
key is at the firont of the stack. Initialization is now complete and service can begin. 

Port serwce proceeds as follows; 

The port whose number is in field SrvRq->Port of the SrvRq entry on the firont of the stack is serviced. This 
SrvRq is then updated; 

SrvRq->RqTime += Intvl(PortNum) 
SrvRq->Intvl = Intvl(PortNum) 

Note that the port rate, and therefore IntvlCPortNum) may change between services of a port. The 
contributing conditions and timing of such changes are specific to the port and not part of this algorithm. 
When port rate changes occur, the external process associated with operating the port will update 
Intvl(PortNum) and the new rate will automatically be incorporated into port service sequencing. 

The SrvRq at the front of the stack is removed and its key is compared with the remaining entries on the 
stack. It is then inserted in the location its key dictates. 

The front SrvRq on the stack now indicates the next port to be serviced. 

It is appropriate to note that there are several methods to accomplish comparison and location of keys on the 
stack. Binary search and balanced tree indexing are two examples. The search/compare method is not part of 
this invention. 
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Beaded Buffer Pointer Chain With Intermediate Pointers 



Description of Related Arts 

Data switches have evolved through a number of stages. The early switches simply moved data into RAM 
from one port and forwarded it out from RAM to another port Modem switches contain several processes 
such as protocol engines and interworking fimctions. Data parcels are not passed from process to process, 
rather they are stored once and pointers to the data is passed from process to process. 

In order to support Quality of Service (QoS), multiple pointer queues are required. Queuing and dequeuing 
become a major portion of the overhead. Switch performance becomes highly dependent on queue 
architecture. 

Multiple data queues combined with ntultiple processes acting on each data queue means at least two sets of 
interrelated queues with some type of links to each other. Each time a process touches a data parcel, one or 
more entries is queued and dequeued at least once and often more than once. 

Some parcels are really pieces of larger parcels. Examples are ATM PDUs made of many ATM cells or 
fragmented IP packets or Fragmented Frame Relay frames. Processes that need to work on the larger parcels 
must either assemble them into new buflFers or form another layer of pointers to track the larger 
demarkations. 

Figure45 below illustrates prior art multiple queues associated with a buffer pool. 

Multiple Queues for Multiple Processes 

For each queue there is a pointer to the oldest and newest entry, often referred to as head and tail (or tail and 
head ... there is no consistency in common practice). Each entry contains a pointer to the next entry. Some 
architectures are bidirectional meaning that each entry contains pointers both to the next and to the previous 
entries. 

Moving an entry from one queue to another requires updating a total at least four and sometimes sbc or eight 
pointers. Since large numbers of queues are involved, these pointers are often stored in RAM rather than 
renters so this amounts to considerable overhead. 

The overhead of moving an entry from one queue to another can be understood by an example. 

Assume two queues names Ql and Q2. They have pointer in RAM addresses Ql_01dest, Ql_Newest, 
Q2_01dest and Q2_Newest. Moving an entry from Ql to Q2 involves the following RAM accesses: 

Tmpl = Ram(Ql_01dest) 
Tmp2 ^ Ram(Q2_Newest) 
Tmp3=Ram(Tmpl) 
Ram(Ql_01dest) = Tmp3 
Ram(Tmp2) = Tmpl 
Ram(Q2_Newest) = Tmpl 
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Summary of the Invention 



This invention is an improvement in queuing architecture. It combines muhiple queues into a single queue, 
significantly decreasing the overhead as data parcels are passed fi"om process to process. 

The invention implements a qu^e with additional pointers. It contains oldest and newest pointers as in a 
traditional quaie. Between these, it also contains first process, second process, etc. pointers. 

When a process advances fix)m one data parcel to the next, it doesn't dequeue and requeue, but only follows 
the chaining pointer to the next parcel This reduces the overhead considerably. 

These queues are organized on a per-flow basis. As such, they identify parcel sequencing order within the 
flow. This eliminates the need to reassemble larger parcels fix)m smaller in a way that will be described later. 
This also reduces overhead and provides significant flexibility in process inq)lementations. 

Figure 46 below illustrates a single queue with pointers to service multiple processes, according to the 
present invention. 

The overhead of advancing a process fi-om one entry to the next can be understood by an example. 

Assume one queue with an intennediate pointer at RAM address Ql_Proc3. Advancing an entry involves the 
following RAM accesses 

Tmpl = Ram(Ql_Proc3) 
Tmp2 = Ram(Tmpl) 
Ram(Ql JProc3) = Tmpl 

Detailed Description of the Invention 

As background to understand the invention, the passage of a data parcel through a typical switch will be 
described. 

Data parcels in a particular flow typically pass through the same ordered set of processes. The life of a data 
parcel within the switch beg^is when the parcel is received fi-om a port and stored in a data buflFer. Via 
pointer passing, it is handed to process#l then process#2, etc. until it is finally sent out on a port and its data 
buflFer released back to a fi-ee buflFer pool. 

When a data buflFer is first allocated for storing a pa rcel, a pointer is removed €rom el firee queue and put onto 
the service queue for the first process that will manipulate the parcel When the first process is finished with 
the parcel, its pointer is removed from the first process queue and put onto the second process queue. This 
continues until the last process is finished with the parcel at which time the parcel is sent to an output port 
and its pointer is put back on the free queue, making it available for reuse with a new incoming parcel. 

To understand the overhead of removing a pointer from one queue and putting it on another queue, it is 
necessary to understand queue structure . 

The queue structure 

A set of chaining pointers are associated with a buflFer pool There is a one to one correlation between 
chaining pointers and data buflFers . The first chaining pointer is associated with the first data buflFer and so 
on. Data parcels in a sequential flow will be stored in \^tever data buflFers are free. The corresponding 
chaining pointers link the parcels together in the proper sequence. 
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Two end-Pointers are assodated with each ouaie. These point t o the oldest and newest pointers in the chair^ 
of buflFers waiting for service . 

Removing the oldest pointer from a queue begins with reading the end-pointer that points to the oldest 
buflfer pointer. This value provides the address in the bufifer pointer table from whidi to read the next pointer 
in the chain. The value read from this location is then written into the oldest end-pointer. Thus two memory 
reads and one memory write are required to remove a pointer from a queue. 

Adding the pointer to another queue, on wlrich it win become the newest pointer, consists of reading the 
end-pointer to the newest biaflFer. The address of the pointer to be added is stored in the location retrieved 
from the newest end-pointer. Then the address of the new pointer is written into the newest end-pointer. 
This amounts to one read and two writes.. 

In summarv. each time a pomter is transferred from one quaie to another, a total of three memory reads and 
three memory writes are performed . 

The invent ion places intermediate process pointers between the newest end-pointer and the oldest end- 
pointer . 

When a new pointer is moved from the free queue to the overall queue or from the overall queue to the free 
queue, it still requires three reads and three writes. The first time a process acts on a cell in such a queue, it 
will read its intermediate pointer and find it zero. It then has to read the oldest end-pointer and store that 
value in its intermediate pointer. This requires a total of 2 rea ds and I write . This is half the memory 
operations that would have been required to remove from one queue and add to another. On subsequent 
actions within the same queue, the intermediate pointer will be non-zero. In this case, the process reads the 
new pointer value fi^m the address it read from its intermediate pointer. Again, there is a total of 3 memory 
accesses, half as manv as would have been require d to remove fi-om one queue and add to another 

Thug, the Qveriiead with a multiple pointer queue can represent nearhr a 50% decrease over the traditional 
queue per process overtiead. 

The other important aspect of the invention is that the queues are per-flow . This means that all the data 
parcels in buffers for a particular flow are sequentiaHv chained in the queue . The intermediate pointers tell 
how fer along the chain each process has worked. It is no longer necessary for processes to reassemble 
parcels into super-parcels in order to have all the data of the super-parcel available. The nature of process 
that operate on super-parcels is that thev are the last process to operate on the chain. They simply leave their 
parcels on the chain until the last parcel of the super-parcel shows up, then process from the oldest to their 
intermediate pointer, releasing pointers as they go. This reduces botii overhead and complexity. 
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Fractional Interval Times for Fine Granularity Bandwidth 

Allocation 



Description of Related Arts 

Most ceil scheduling algorithms contain a parameter which is the number of cell times between a particular 
yCs cells. For example a 64 Kbps VC nmning on a 2.048 Mbps line would occupy every 32nd cell slot so 
its interval time would be 32. The scheduler attempts to assign every 32nd cell time to this VC. If the cell 
slot is already taken by another VC, then a priority check is made. The higher priority QoS gets the slot and 
the lower priority VC gets bumped to the ne?ct free time slot. 

Rates allowed by this mechanism are line rate, line rate /2, line rate /3, Kne rate/4, etc. The range of rates 
depends on the number of bits in the divisor. For example, a 10 bit divisor accommodates line rate down to 
0.1% of line rate. At lower data rates, i.e. line rate over large divisors, the steps from one possible rate to the 
next are small. At higher rates, however, the steps are large. For example, the first programmable rate lower 
than Ime rate is 50% of line rate. The next smaller programmable rate under 50% line rate is 25% line rate. 
Smaller steps at the high end would be desireable. 

Summary of the Invention 

The invention defines interval times as fixed point Sectional numbers, Le. each number has n bits of integer 
portion md m bits of fi^ctional portion. The number of integer and flection bits depends on the range of 
r^tes and the desired granularity. For example, 10 integer bits plus 4 fractional bits allows a dynamic range of 
line rate down to 0. 1% of line rate. The first step below line rate is 94% of line rate. Granularity rapidly 
improves as rates decrease. The step below 50% is 48.5%. 

Detailed Description of the Invention 

In the example implementation, for each flow there is defined a 16 bit non-mteger mterval time, 
"Intvl(FlowNum).** This breaks down into the most significant 12 bits which contain the integer portion, 
"Intvl(FlowNum>->Int," and tiie least significant 4 bits which contain the finctional portion, 
"Intvl(FlowNum)->Frct." 

A port time, "PortTime", is maintained which is a count of cell time slots experienced by the port. This is a 
14 bit integer. 

Another 16 bit non-integer is maintained for each flow. This number, "TgtTime(FlowNum)" breaks down 
into a 14 bit integer field, "TgtTime(FlowNum>>Int" and a 4 bit fraction, "TgtTime(FlowNum)->frct." 

Initialization: 

When a flow is initially defined, it's Intv(FlowNum) is also defined. Its initial value of TgtTime(FlowNum) is 
calculated from Intv(FlowNum) and PortTime. Specifically: 

TgtTime(FlowNum>>Int = PortTime + Intvl(FlowNum>->Int 
TgtTime(FlowNum)->Frct = Intvl(FlowNum)->Frct 



Operation; 
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Each time a ceU slot passes for the port. TgtTime(nowNuin>>Int is compared to PortTime. (Actually, it is 
placed in queue ordered by TgtTime(FlowNum) and the first entry in the quaie is compared to PortTime. 
When this flow's time and QoS priority arrive, it wiU find itself at the fi-ont of the queue and its time wiU be 
compared.) When PortTime becomes equal or greater than TgtTune(nowNum)->Int then a cell fi-om 
FlowNum is to be sent. 



After its cell is sent, the target time for the next cell is calculated: 

TgtTime(FlowNum) = TgtTime(nowNum) + Intvl(FlowNum) 

Note that this time the entire Intv, inchiding both fi^ctional and integer parts are added to the entire target 
time. This may or may not result m cany firom the fi-actional to the integer portion. 

The new target time is now ready to be compared once again to the port time, repeating the process 
beginning under Operation above. 

This simple process of accumulating the firactional buildup fi-om tiie interval time into the target time 
automatically adjusts the repetition fi-equency for transmitting the flow's cells on tiie port to match the 
desired non integer rate for the flow. 

One detail is not part of the invention but should be noted. As there is a finite number of bits, overflows may 
occur. Comparison logic obviously has to take tiiis into account to maintain proper order in tiie target time 
queue and to make meaningfiil comparisons against port time. 

Example: 

As an example we consider a Tl transmission rate that corresponds to 1536 Kbps (Kilo Bits per second) of 
user data rate. If we choose to use 950 Kbps of this for our port cell flow. 
1536 divide by 950 = approx. 1 5/8. 

This translate mto transmitting one ATM cell every 1 5/8transmit opportunities 

If we add 1 5/8to itself sequentially we'll have tiie following sequences of Sectional numbers* 

0, 1 5/8, 3 1/4, 4 7/8, 6 /i. 8 1/8, 9 Va, 11 3/8, etc. 

The ATM data cells are transmitted at the integer portion of tiie above sequences, i.e. 0.1,3,4,6,8,9,1 1, etc. 
An ATM idle cell is inserted at the other intervals. The table below shows this data flow. 
The PIC count ^Port Interval Counter) keeps track of the following sequences 

™ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 

I I I I I I I I 

OD D DD D DD D DD DD 

D 

I = IdelCens 
D= Data Cells 
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Multiple Preemptive CBR's for Precise Port Pacing Control 



Description of Related Arts 

There is sometimes a requirement to limit the effective bandwidth of an ATM port to a rate below 
the line rate. For example, in the case of a customer that is purchasing lower network bandwidth 
than the local loop is capable of canying. 

There are several ways of accomplishing this. 

1 . The network ingress port can police, i.e. discard any cells over the desired bandwidth. This 
restricts data coming into the network but has severe negative impact on the service seen by the 
customer. Data applications become extremely slow with even slight data loss. Discarding even 
a small percentage of cells renders the network service unusable for data applications. Voice 
and video quality suffers too. though not as severely as data applications. 

2. Individual flows can be assigned peak rates with no overbooking. This is a way of limiting the 
total proffered data out of a port but is not a practical solution except in a few limited 
applications. Dedicating fixed bandwidth to data connections results in poor overall bandwidth 
utilization because they tend to be bursty. UBR service was conceived precisely so this 
application type could more effectively share the network pipe. 

3. Add hardware to dock outgoing cells to a port at a lower rate than the port can fonA^ard them. 
This is not a particularly desirable solution because it adds synchronous time features to the 
switching function that would othenvise only be concerned with cell sequencing. 

Solution number 3 is the most common. 

When ports are limited in rate. i.e. throttled below their line rate, there is often an issue with rate 
granularity. The reason is that the switching function deals in cell slots. Using every cell slot 
yields line rate. Every other slot yields 1/2 line rate. The lower the throttled rate, the finer the 
achievable granularity. 5% or 10% or 1 5% are achievable but if 80% or 85% or 90% is desired 
the close choices may be 50% and 1 00%. 

Summary of the Invention 

The invention employs from 0 to several GBR cell flows which contain idle cells instead of data. 
These idle cells are transmitted exactly as data cells would be so the clocking is a function of the 
port PHY rather than the switching function. The switching function is therefore not burdened 
with network clocking and synchronous scheduling but is only required to do what every 
switching function already does. 

When this invention allocates bandwidth to a CBR flow of idle cells, it effectively subtracts the 
programmed peak rate of the idle stream from the line rate. This has the benefit of fine 
granularity at high remaining port bandwidth since in this case the amount being subtracted is a 
programmed value that is a small percentage of line rate. 

Use of multiple idle CBR flows has the advantage of providing fine granularity across the entire 
bandwidth range. 
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Partitionable Page Shifter With Self Timing Xor Chain 



Description of Related Arts 



One of the most eflfective mechanisms to schedule data transmission is via a flow transmission request queue 
ordered by target tmie. This mechanism has its chaUenges, however. Inserting and deleting to/from an 
ordered Lst requires shifting parts of the list up or down which can create long access times and high 
overhead. °^ 

There^ Several approaches to this problem, ranging from very slow and hi overhead bubble up/down to 
more effiaent block shifts. Block shifts are gate intensive but greatly increase performance. 

mwk shifting typically involves loading the right data into the shifter, shifting up or down and storing it 

Anothw challenge is that time values in the list typically increase monotonically and eventually overflow 
When this happens, values that should be large appear smaU and vice versa so the comparison fimction 
becomes very complex. 

Summary of the Invention 

The Partitionable Page Shifter is a key component in schedule queue processing. It is the component that 
ordered queue entnes up and down in order to insert or delete an entry. This invention provides features that 
significantly improve the perfonmance of processing ordered scheduler request queues. 

The first feature is the ability to partition the queue into multiple segments that can then be shifted up or 
down durmg a smgle clock. This feature enables block shifting to take place without loading and unloadina 
partial sections into the blodc shifter. 

The second feature is the abflity to efficiently determine the amount of time needed for logic to settle before 
performing the shift. The logic chain involved in defining shift partitions includes a string of XOR gates. The 
invention includes a mechanism for determining when control has propogated through the chain and is ready 
for the shift operation. 

The third feature is the ability in a single clock cycle to adjust all queue entries for target time wrap. With 
this feature, time counters stay in a valid range for comparisons. 

Detailed Descciption of the Invention 

The first feature of the invention is assodated with shifting entries up and down. There are two unique 
aspects to this feature. The first is the ability to partition the list into shifted and non-shifted areas. The 
second is avoiding excess waiting for partition control logic to propogate through the system before 
performing the shift. 

The Partitionable Page shifter contains ordered entries. Each entry contains a time value and otiier 
infonn^oa The entries are ordered by time value. Time value fields contain at least more bits than tiie 
iMgest increment tiiat wll be applied to tiiem, assuring tiiat any wrap that takes place can not affect more 
than the most significant bit of the time field. 
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A shift operation is performed as follows: 



1 . All flip flops are cleared 

2. ~ 



3. 



S^ToX' fiSlT "7 '^'^''"^ and set. As a result, shifting is disabled from before the first 
^ to the firs^ set flip flop, then enabled from the first to the second set flip flop then disabl^ 
from the second set flip flop to the third and so oa up wen oisaoiea 
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The following are third party software building blocks used in the Mako-Dexter 3000: 

1) TELOGY, Germantown, MD: 

- Basic Access Switched Mode Client uP Component with TSGM and ISDM 

- AAL2 DSP with G.71 1 / 729AB / 726 / 727 voice codecs and std. fax relay 
(also supports Telogy 13 proprietary encaps.) 

2) INTEGRATED SYSTEMS / WIND RIVER SYSTEMS, Alameda. CA: 

- pSOS Single Processor Operating System 

3) INVERNESS SYSTEMS LTD., Kfar Saba, Israel (Virata): 

- AALO / AAL5 drivers 

- AF-VTOA-0075.000 CES Intenworking 

- MPC860 drivers and system services 

4) TELENETWORKS (Next Level Communications, Rohnert Park, CA): 

- ISDN BRI ETSI Net3 and DL Core (Network Side) 

- ISDN BRI QSIG Layer III 

- ISDN PRI ETSI Nets and DL Core (Network Side) 

- ISDN PRI QSIG Layer III 

- Q.SAAL 



171 



E^jjress Mail #EJ130608565US 
Attorney Docket MOl 5-1001 




iTeiriet 



Serial 
Port 
Driver : 



Gdntrol^&:: 



n;r4;!C*)nfigui5^ 



SNMP: 



tFTP-= 



:'ieMP: 



Signaiing;; 



llJHeiium-;/^ 
. Brid^ihg 



^J^cPt; 

^ SVnd 



. . fHeliuriri;.: 

■■•*<-SAR:-"- 



Helium;:: 
lOBT Driver^ 



rip: 



..ATMOS Kernel 



Dexter 




ATM 
Switch 



Branch Offices 



Host 
System 



Central Office 



ATWFR T1/E1 




(S) 

ACT ® 1 -j 


<S) 



(S) 



ACT ® ® < 



□□no 



ATMTI/eilMA 



ACT 



HHHOi 



(S) 



ATBA DS-3 



ACT O 



L 



ATME3 



0 ACT 2 ff0 





® 



FRV.3S/X21 



ACT % / ad<5ddddoddoad \ 

LNK O V w OOOOOOQOOOOO J 



0 



0 




ATM/FR SDSL 






ATIWFR HDSL2 





0 



Switched lOrtOOBaseT 

0 



ACT 

INK 



7 



PBXTl/El/PRi + BRI 

0 



ACT ®® 
IKK 99 



ISDN BR] 

0 



ACT 9Q 
LNK 99 



(SDN BRJ 

0 



ACT 99^ 



Dm 



0 



PBXT1/E1/PRI 






0 



0 



0 



0 



Rag Header 



RFC 1430 
Header 



Ota Upper 


cm 1 £A-ob 


Ota Lower 


1 FECN 1 BECN 


OE 1 EA>1 1 



ATM Cell Header and Payload 



I 



User traffic 



FCS Flag 




U4 



GFC = Generic Row Control 
VPI = Virtual Path Identifier 
VCI = Virtual ConnecUon Id. 
PT = Payload Type 
CLP = Cell Loss Priorfty 
HEC a Header Error Checksum 





LI 



PBX 



/J 



< CO 



So: 




CO 
O 





-J <: 



O 



o 



CO 



or: 



LU 
UJ 


LtJ 




3no 



§1 

CD Q 




-J 
—J 


CO 
LU 


LU 

o 





' a. 01 

CO Q 





^ 


3 


o 

LU 






HD 


CO 












or 
o 

CO 
UJ 

o 
a: 



OQ 



a. 




o 






CJ 



-© 



CL 
rCD 



ro O 

-J CO 
LjJ LaJ 



o 
o 
or 



UJ 

3 CO 

cr iS 

UJ —J 
U. UJ 

ZD 
CD 




or 





CO 





CELL 
DEL 


r" 




HOLC 
CODER 






2 X 

Q => 






DItNimibex , 

r^B.-i"* nc ,^ ,^ . . _ ^ 








i.ijlJjliijiljlUj j g |7 jC j U 1 -j 




Overflow 


Next Target Switch Time 


Time 
Fraction 


Ci Number or 
Port Number 


- Quality 
-jf Service 



BT Top Boundary, Register 2047 



Unused Registers Bottom Boundary, 
Port #M Top Boundary 9 or 17) 



Port #2 Bottom Boundary, 
Port #1 Top Boundary 



Port #1 Bottom Boundary, 
Port Schedxding Top Boxindary 



Port Scheduling Bottom 
Boundary (Register 0) 



Available (Kmptyj registers 
for additional Ci*s 



Repeated .as need for the 
number of ports in 
configuration 



Port Hi Schf fluling 



Registers 



J>oit Scheduling 



Registers 



Top Most Level BT Configuration 



Location 
4 



-mnramrgar 
SwSch Time 

e 



— pan — 

Number 



tmwaj vaiUQ la oa adcsd 

for next Switch Time 
6 



Enitial Port Sgftinb with 4 TDM Ports 



Uocatbn 

e 


SwftchTime 
16 


Number 
9 


for naxt Switch Ttme 
16 


7 


14 


a 


18 


6 


12 


7 


16 


5 


10 


6 


16 


4 


8 


5 


18 




6 


4 


16 


2 


4 


3 


18 


1 


2 


2 


18 


0 


1 


1 


2 




Imtiai i'ort Settir 


gs with i 


)M Ports 



Inmal BT 



InHial Target 



Port 



Interval Value to be added 



location 
18 


SwHch Ttme 
32 


Number 
17 


for nexi Switch Time 
32 


T3 


30 


re 


32 


rt 


28 


ta 


32 


^^ 

« 


28 


w 


32 


« 


24 

22 


« 

« 


32 

as 


^ 


30 


M 


33 


s 


la,,.- 


-113 


32 


ft * 




Q 






^A 


H 


'\0 


6 


12 


r 


32 




Ifl 


6 


^2 


4 


8 


S 


32 


3 


8 


4 


32 


2 


4 


3 


32 


1 


2 


2 


32 


0 


1 


1 


2 




nitial Port Scttinj 


s with 16 T 


])M Ports 











3/ 




BT 



ScttQ<tul8 a Oo b4 
described tn delei 



Tar 


? 




? 


5? 


a 


















c 










n 






1 








e 




s 


e 




I 


10 



=1 







Tar 






z 




=! 








i 








14 




s 





■VlG4f ep- 



-4cU 



C«i (rem 
Porti 



E2U 



C«i (horn 

SaajL 



C«l from 



Saoi 



C«l from 

PQrt4 



C«i tnm 

SSflLl 



C«l from 
_P2!tl 



Cfl (Torn 
_£2I11 



^ofrtATt tteTns triTintg frr.TnkVifci ^aTn|||^' TVi^ Prlrt-< arg fllwkv^ m Tar^rt TiTtie rfn nrrlftr 



IWhcnthc 





71-7? 


70 






5M7 


. 57-64 . 
















1 














tnlep/al Value 


Descriptlor 


ajlure Use = 


o 
o 

o 

i 

sr 

or 
CD 


Q 
o 

A 
3 

n 

§■ 
I 


Q 

3 
□3 
H 


J 


Cumulative 
Consecutive 

Empty. 

Cells 

m It 1 ■ 


Maximum 
Consecu^e 
Empt/ 
Cells 


CumulaQve 
Court per 
Time Measure 


Maximum 
Count per 
Time Measure 


Fulure Use | 


in 12.2 formal 



STEP1 



STEP 2 



STEP 3 



STEP 4 



Ci ACTIVATION PROCESS 



-Y«s 



WailforQSwaJertor 
ClAq going from fuU to 



Rssd and nxnoN^ first 
•ntry tn Switch Quoim. 




Ptaca 01 on CiAq (a 
Activation quwM) and 
S«tOActhm 



CTs are actually 
activated by th« 
Scheduler Process 



BPtr 



6KB 



BPId 



156 KB 



URT 




ordered 
by key 



10 KB 



TRT 




lOKB .. 



CiPtr 



CUn 

(16b) 

CiSch 

(16b) 

CiPktFrm 

(16b) 

OOut 

(16b) 

13 KB 



IRT 



UXT 


TXT 


VPI(16) 




Port 


VCI(16) 




(4b) 


.Msl<32 




Chan 


F=wdg(l 




(5b) 


RtAtm 


FrHdr 


(1) 




(32b) 


RTEth 




AAL 


(1) 

FwdCI 




(3b) 




(13) 


12 KB 



6KB 



ST 




IntvlTime 

(Mb) 

Qos (3b) 

Curr/M 

(10b) 

MaVM 

(10b) 



10 KB 




rortiNumbm 
-tJ ■ — 


"PoFFTypi 




Client riumber 


Luent lype 


-r=TW — 


"Sehdduifti'; 




-0 


-cpv — ' 


65 - 1022 


Utopia PHY 

-TDM 




-1 


-pcm 


-zm ■ 


Lucdl Puil 




-2 ' 


-TBW 








-3t4 


' OUicdulw 













Table 



URT 



UrtBase 



Register 



Width 



44 b 



Estimated Size 
10 KB 



pUfU . 1 


1 TrtBaco 1 


|-4ai 1 


1 10 KB 1 











Tables indexed by Ci 



Table 



CiPtr 
UXT 



Re^ster 
CiPtrBase 
UxtBase" 



Width 



64 b 



Estimated Size 
10 KB 



TXT 


TxtBase 


44b 


12 KB 


ST 


StBase 


51b 


10 KB 


XT 


XtBase 


24b 


6KB 


















I'ables indexed by CI 

TST 

I 


tiannel (Fort) rsumber 

TstBase 76b 5 KB 



Tables indexed by BN 



Table 

rSPt 1 


Riegister 


Width 


Estimated Size 


-BPid 




ri2 — 1 


r&«B 1 




DtJldDaae 


-52 


1 56 i<D 



FIFO 



The FIFO are stored in off-chip RAM. The FIFO sizes will be decided' after simulation. 



FIFO 


Width 

16b 


Estimated Size 

■mn 


PktOut 


16b 


TBD 


CellOut 


16b 


TBD 


LocalOut 


I6b 


TBD 









Bit 


Description 


0 


Unknown frame coiant >= 1 28 


I 


Bad frame count >« 128 


2 


Uverflbw frame count >=» 128 


3 


Unloiown ceil count >« 128 




Bad cell count >« i2« — • 




Uveruow ceil count >= 128 ' 
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RamRq 
BjuttAk 



lUaiAdr 



FnxiDmtAviU 
PnnSof 
FrniDUEUICtk 
FnnDsOa' 

FnnSegAk 



. ► 


TnnRe 
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<. 
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► 
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► 
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RunAk 



lUinRcfDat 
BunAdr 
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FIFO 



FIFO 



FIFO 



1^ 



FIFO 



QoS 
Scheduler 



QoS 
Scheduler 



Scbediiler 



QoS 
Scheduler 



FIFO 



Priority 
Selector 



FIFO 

■FIFO 1^^^ 



FIFO 



FIFO 1"^^ 




Proccsi I queue 



Process 2 queue 



Process queue 



(45- 



Data Buffers 




Flow queue 



Flow queue 



Newest 


► 


Proce.v.q#2 






Olde-st [ 



Pointer moved 
from \ Si process 
and put to 
2nd process 




Data Buffers 



ATM/FRT1/E1 


Network module to conned to ATM 
or Frame Relay WAN. 


3-5 


ATMT1 orE1 IMA 


Network module to connect to ATM 
WAN. Supports grouping of multiple 
ATM links into single VC. 


3-6 


ATM DS-3/E3 


Network module to connect to ATM 
WAN. 


3-7 


ATM 0C-3/STM-1 


Network module to connect to ATM 
WAN. 


3-8 


ATM/FR SDSL 


Network module to connect to ATM 
or Frame Relay WAN over DSL. 


3-9 


ATM/FR HDS1_2 


Network module to connect to DSL 
WAN. Configurable for ATM or 
Frame Relay. 


3-10 


PD \/ IK/V O-l 

rr\ V.OC3/A.2 I 


Network or User module to connect 
router or other Frame Relay device. 


3-11 


Switched 
10/100BaseT 


User module used to connect local 
Ethernet hub or switch. 


3-12 


PBXT1/E1/PRI 


User module to connect local PBX 
equipment 


3-13 


PBXT1/E1/PRI + 
BRI 


User module to connect local PBX 
and ISDN BRI. 


3-15 


ISDN BRI 


User module to connect up to 3 Sn"/U 
devices. 


3-16 



Table 1 Module List Description 



